Dear Experts, After one of updates that was released some time ago (a Month ago or maybe even earlier) I have noticed the following. On the machines with default runlevel 5 (sorry about old terminology, the new one is still confusing for me ;-) GUI/X11 login (display manager) lists only users whose default shell is bash. Or, at least users whose default shell is tcsh are not listed at all, and if they attempt to log in just by giving their UNIX username, their X11 session "crashes", meaning that after attempting to start, it just trows one back to GUI/X11 login screen. I really do not want to start this shell vs that shell flame war (especially that I myself prefer not tcsh but sh and/or bash for scripting...). But I respect my user's freedom of choosing default shell, so this is really big issue IMHO. I just wonder: does RedHat (CentOS's upstream vendor) dislike and is willing to eradicate all shells except for bash, or what I see is just my own pilot's error? Thanks in advance for all your answers. Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Stephen John Smoogen
2017-Dec-15 20:34 UTC
[CentOS] GUI/X11 login and shells other than bash?
On 15 December 2017 at 13:24, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:> Dear Experts, > > After one of updates that was released some time ago (a Month ago or maybe > even earlier) I have noticed the following. On the machines with default > runlevel 5 (sorry about old terminology, the new one is still confusing > for me ;-) GUI/X11 login (display manager) lists only users whose default > shell is bash. Or, at least users whose default shell is tcsh are not > listed at all, and if they attempt to log in just by giving their UNIX > username, their X11 session "crashes", meaning that after attempting to > start, it just trows one back to GUI/X11 login screen. > > I really do not want to start this shell vs that shell flame war > (especially that I myself prefer not tcsh but sh and/or bash for > scripting...). But I respect my user's freedom of choosing default shell, > so this is really big issue IMHO. > > I just wonder: does RedHat (CentOS's upstream vendor) dislike and is > willing to eradicate all shells except for bash, or what I see is just my > own pilot's error? >Just for future advise.. for someone who says they don't want to start a flamewar.. you worded that pretty much like you wanted to start a flame war. This was simple to test. 1. I installed RHEL-7 in a virtual machine. 2. I created an account with its shell /bin/tcsh [useradd ssmoogen -s /bin/tcsh ] 3. I went to the login screen. There was an ssmoogen there 4. I logged in as ssmoogen. I got a GNOME desktop 5. I opened a terminal and my shell was tcsh. That took me 10 minutes. Due to this I am going to say that there is something wrong with other parts of the start up environment from what the shell is listed as in /etc/passwd, if the user has specific startup scripts .xsession items or some similar problem based on 'shell cruft'. People who work on many different systems have to regularly add exceptions and special cases or unadd them when they find stuff breaks. I would also check to see if there is a post configuration setup which changed /etc/shells on the system. Another common problem is that the shell or startsups are looking for /usr/local/bin/tcsh which doesn't exist. Red Hat has a lot of different developers using pretty much every shell that is shipped in RHEL and some which aren't even in Fedora. The developers also use all kinds of different desktops and software.. while this doesn't mean bugs won't happen.. it does mean that if 'Red Hat' was out to eradicate other shells, there would be posts on every hacker site from Red Hat employees who wouldn't put up with it.> Thanks in advance for all your answers. > > Valeri > > ++++++++++++++++++++++++++++++++++++++++ > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > ++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- Stephen J Smoogen.
On Fri, December 15, 2017 2:34 pm, Stephen John Smoogen wrote:> On 15 December 2017 at 13:24, Valeri Galtsev <galtsev at kicp.uchicago.edu> > wrote: >> Dear Experts, >> >> After one of updates that was released some time ago (a Month ago or >> maybe >> even earlier) I have noticed the following. On the machines with default >> runlevel 5 (sorry about old terminology, the new one is still confusing >> for me ;-) GUI/X11 login (display manager) lists only users whose >> default >> shell is bash. Or, at least users whose default shell is tcsh are not >> listed at all, and if they attempt to log in just by giving their UNIX >> username, their X11 session "crashes", meaning that after attempting to >> start, it just trows one back to GUI/X11 login screen. >> >> I really do not want to start this shell vs that shell flame war >> (especially that I myself prefer not tcsh but sh and/or bash for >> scripting...). But I respect my user's freedom of choosing default >> shell, >> so this is really big issue IMHO. >> >> I just wonder: does RedHat (CentOS's upstream vendor) dislike and is >> willing to eradicate all shells except for bash, or what I see is just >> my >> own pilot's error? >> > > Just for future advise.. for someone who says they don't want to start > a flamewar.. you worded that pretty much like you wanted to start a > flame war.Thanks a lot! Well, not flamewar about different shells, but some acid about something that broke on enterprise kind of system somewhere in the middle of its life cycle. Well, "nothing changed" apart from installation of a bunch of updates. This and another system which misbehaved were two or so months behind on updates - my fault - and were fully updated in one go. And, of course, I still don't exclude pilot error ;-) Of course, being not native English speaker, I didn't manage to express my bitterness about system, not shells whichever were mentioned. My alopogies.> > This was simple to test. > > 1. I installed RHEL-7 in a virtual machine. > 2. I created an account with its shell /bin/tcsh [useradd ssmoogen -s > /bin/tcsh ] > 3. I went to the login screen. There was an ssmoogen there > 4. I logged in as ssmoogen. I got a GNOME desktop > 5. I opened a terminal and my shell was tcsh. > > That took me 10 minutes. Due to this I am going to say that there is > something wrong with other parts of the start up environment from what > the shell is listed as in /etc/passwd, if the user has specific > startup scripts .xsession items or some similar problem based on > 'shell cruft'. People who work on many different systems have to > regularly add exceptions and special cases or unadd them when they > find stuff breaks.Thanks a lot! I will go thoroughly through user in question ~/.cshrc. Indeed, freshly created user with tcsh as default shell does successfully log in and X11 does not crash on him. One pilot error: I didn't check that before bugging everybody...> I would also check to see if there is a post > configuration setup which changed /etc/shells on the system. Another > common problem is that the shell or startsups are looking for > /usr/local/bin/tcsh which doesn't exist.Quick test with creating user with shell /bin/tcsh makes user successfully shown on GUI login. However, changing that user's shell to /usr/bin/tcsh makes user disappear from GUI login. And the second (/usr/bin/tcsh) in actual location of tcsh binary, whereas /bin/tcsh involves symlink /bin --> /usr/bin ... My other playing around with making different default user shells didn't always yield reproducible results... so I'll postpone anything conclusive till later. But looking into /etc/shells (Thanks again!!) shows that only bash gets unique privileged treatment, namely> > Red Hat has a lot of different developers using pretty much every > shell that is shipped in RHEL and some which aren't even in Fedora. > The developers also use all kinds of different desktops and software.. > while this doesn't mean bugs won't happen.. it does mean that if 'Red > Hat' was out to eradicate other shells, there would be posts on every > hacker site from Red Hat employees who wouldn't put up with it. > > > >> Thanks in advance for all your answers. >> >> Valeri >> >> ++++++++++++++++++++++++++++++++++++++++ >> Valeri Galtsev >> Sr System Administrator >> Department of Astronomy and Astrophysics >> Kavli Institute for Cosmological Physics >> University of Chicago >> Phone: 773-702-4247 >> ++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > > > > -- > Stephen J Smoogen. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 12/15/2017 10:24 AM, Valeri Galtsev wrote:> if they attempt to log in just by giving their UNIX > username, their X11 session "crashes", meaning that after attempting to > start, it just trows one back to GUI/X11 login screen.Log in over ssh and run "journalctl -f" while such a user attempts login.? Do you see anything useful logged after the user attempts login?
Reasonably Related Threads
- GUI/X11 login and shells other than bash?
- GUI/X11 login and shells other than bash?
- bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh)
- FreeBSD Security Advisory: FreeBSD-SA-00:76.tcsh-csh
- smbsh - Samba 2.0.7 - Solaris 2.6? Thanks!