Bug 1728330

Moving to gdm, which afaics is the only component that sources any shell configuration.

it's actually /usr/bin/gnome-session that does it:

    exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"•

But since it does it, i'm a little confused why it's not working.

is /bin/ksh in /etc/shells?

  Thanks for the analysis.

  Better checking, I believe this is actually an issue with ksh.

  For example, in rhel8 (but same on recent fedora or rhel7):

[pcpa@rhel8 ~]$ env -i bash -l -c 'echo $SHELL'
/bin/bash

[pcpa@rhel8 ~]$ env -i ksh -l -c 'echo $SHELL'
/etc/profile[59]: id: not found [No such file or directory]
/etc/profile[59]: id: not found [No such file or directory]
/usr/libexec/grepconf.sh: line 5: grep: command not found
/usr/libexec/grepconf.sh: line 5: grep: command not found
/usr/libexec/grepconf.sh: line 5: grep: command not found
/etc/profile[70]: .[248]: sed: not found [No such file or directory]
/bin/sh

ksh does not have a reasonable default $PATH and "really" sets $SHELL to
bash as /bin/sh is a symlink to bash.

  This issue was initially reported to gnome-session, but the problem should
be indeed with ksh.

  In the previous comment it shows that ksh does not have some good defaults
for both $PATH and the default $SHELL actually is /bin/sh.

  This causes problems on graphical login, as .profile ends up not being sourced
when an user has /bin/ksh as user login shell.

not sure i understand what you're saying.

SHELL and PATH are set by GDM before ksh even enters the picture.

can you attach /etc/shells and the output of

$ getent passwd kshuserhere

hmm seems to work here.  is this wayland or xorg ?

echo $XDG_SESSION_TYPE

While checking a strace, I noticed the user has it set to x11, and
asked the user to test this pseudo patch to /usr/bin/gnome-session:

- if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
- if [ "x$XDG_SESSION_TYPE" = "xwayland" -o "x$XDG_SESSION_TYPE" = "xx11" ] &&

BTW, on my tests, it always executes xinitrc-common, but that is not
the case for the user. Any idea of what might cause that? I ask because
/etc/X11/xinitrc-common sources $HOME/.profile if it exists.

normally it would be decided by the X-GDM-BypassXsession key in the session file in /usr/share/xsessions (defaults to false meaning "run xsession" for x sessions)

User tells the suggest patch to /usr/bin/gnome-session corrects the problem.

Do you have some suggestion on how to further investigate it? I mean, in my
tests, adding:

WaylandEnable=false

to /etc/gdm/custom.conf still properly did source ~/.profile, and the user
does not have any X-GDM-BypassXsession key in the session files under
/usr/share/xsessions.

can you have them put Enable=true in the [debug] section of /etc/gdm/custom.conf, reboot, reproduce and then attach the full journalctl -b output?

Created attachment 1672224 [details]
The proposed fix does not sort the bug for me - see comment

I saw this bug, and I (a different user) am seeing something very similar which is NOT fixed by the proposed fix.

If I understand it right the proposed fix is to recursively call gnome-session via a login shell when XDG_SESSION_TYPE is x11 as well as when it's wayland.

This works for me when my shell is set to /bin/bash . However, it does not work when my shell is set to /bin/tcsh (having yum installed the relevant package).

I was at the time using the X11 GNOME standard Xorg choice at the login screen, and CentOS 8.1 .

The result is that my ~/.login file doesn't get sourced, and my path doesn't start from where it should do.

In order to try to get further with understanding what is going on, I made alternative versions of /usr/bin/gnome-session (and some of the files in /etc/X11/xinit, which I think are irrelevant, though they were relevant when comparing what happens with CentOS 7.7), with filenames appended with .debugging in the attachment, which I put in place of the originals. I put a command to add ~/quack to my path in my ~/.login file. I then tried logging in to see what happens. The resulting file of logging points is attached as /home/rfs/temp/templog . At each logging point the last output is 0 if quack is on the path, and 1 if quack is not on the path.

In tcsh $version gives me "tcsh 6.20.00 (Astron) 2016-11-24 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec". yum list installed tcsh gives me "tcsh.x86_64 6.20.00-9.el8 @AppStream".

As far as I can tell, when my shell is set to /bin/tcsh, when the recursive call to gnome-session is made at line 36 of the debugging version of the file (which has the additional x11 reason for doing a recursive call):

a) The call to /bin/tcsh is indeed made in such a way that the zeroth parameter arriving in /bin/tcsh is -/bin/tcsh, as it should be, to flag that a login shell is wanted;

b) When called at this point /bin/tcsh does NOT result in ~/.login being sourced; but

c) When called by a similar call from a script in my home directory, a virtually identical call does result in ~/.login being sourced (as recorded in the logging file).

I'm afraid that's as far as I've been able to get - the behaviour seems very odd.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1766