Bug 2175675

Can you please provide more information? Is anything crash reported in coredumpctl? Can you attach here your full journal log (restart the machine, reproduce and save the output of `journalctl -b`)?

There was no crash reported by coredumpctl. Unfortunately, I couldn't reboot the system. But here's the redacted log of journalctl:

Mar 06 13:47:56 host.example.com systemd[1]: systemd-localed.service: Deactivated successfully.
Mar 06 13:48:10 host.example.com dbus-daemon[3650521]: [session uid=12884 pid=3650519] Activating service name='org.gnome.Nautilus' requested by ':1.13' (uid=12884 pid=3650644 comm="/usr/bin/gnome-shell ")
Mar 06 13:48:10 host.example.com dbus-daemon[3650521]: [session uid=12884 pid=3650519] Successfully activated service 'org.gnome.Nautilus'
Mar 06 13:48:11 host.example.com systemd[1]: Starting Hostname Service...
Mar 06 13:48:11 host.example.com systemd[1]: Started Hostname Service.
Mar 06 13:48:22 host.example.com org.gtk.vfs.Daemon[3650586]: A connection to the bus can't be made
Mar 06 13:48:22 host.example.com org.gnome.Shell.CalendarServer[3650729]: gnome-shell-calendar-server[3650729]: Lost (or failed to acquire) the name org.gnome.Shell.CalendarServer - exiting
Mar 06 13:48:22 host.example.com evolution-addre[3650789]: Error setting property 'ConnectionStatus' on interface org.gnome.evolution.dataserver.Source: Verbindung ist geschlossen (g-io-error-quark, 18)
Mar 06 13:48:22 host.example.com tracker-miner-f[3651018]: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
Mar 06 13:48:22 host.example.com org.gtk.vfs.Daemon[3651335]: A connection to the bus can't be made
Mar 06 13:48:22 host.example.com tracker-miner-fs-3.desktop[3651018]: OK
Mar 06 13:48:22 host.example.com polkitd[8342]: Unregistered Authentication Agent for unix-session:452 (system bus name :1.21401, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) (disconnected from bus)
Mar 06 13:48:25 host.example.com geoclue[3650777]: Service not used for 60 seconds. Shutting down..
Mar 06 13:48:25 host.example.com systemd[1]: geoclue.service: Deactivated successfully.
Mar 06 13:48:41 host.example.com systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Mar 06 13:48:42 host.example.com sshd[3651476]: error: kex_exchange_identification: Connection closed by remote host
Mar 06 13:48:42 host.example.com sshd[3651476]: Connection closed by xxx.xx.xx.xx port 46146

So this was a one of crash or you're able to reproduce reliably? Would be good to see even the earlier entries from the journal.

I can reproduce it 100%. I'll get back to you as soon as I can reboot the machine.

Created attachment 1948667 [details]
journalctl -b output

Mar 07 13:48:32 el9.example.com systemd[1]: Started User Manager for UID 12884.
Mar 07 13:48:32 el9.example.com systemd[1]: Started Session 3 of User waschk.
Mar 07 13:48:32 el9.example.com sshd[3698]: pam_unix(sshd:session): session opened for user waschk(uid=12884) by (uid=0)
Mar 07 13:48:32 el9.example.com sshd[3698]: pam_afs_session(sshd:session): skipping, AFS apparently not available
Mar 07 13:48:48 el9.example.com sshd[3719]: Received disconnect from xxx.xx.2.20 port 55234:11: disconnected by user
Mar 07 13:48:48 el9.example.com sshd[3719]: Disconnected from user waschk xxx.xx.2.20 port 55234
Mar 07 13:48:48 el9.example.com sshd[3698]: pam_unix(sshd:session): session closed for user waschk
Mar 07 13:48:48 el9.example.com sshd[3698]: pam_afs_session(sshd:session): skipping, AFS apparently not available
Mar 07 13:48:48 el9.example.com systemd[1]: session-3.scope: Deactivated successfully.
Mar 07 13:48:48 el9.example.com systemd-logind[2612]: Session 3 logged out. Waiting for processes to exit.
Mar 07 13:48:48 el9.example.com systemd-logind[2612]: Removed session 3.
Mar 07 13:48:53 el9.example.com sshd[3841]: error: kex_exchange_identification: Connection closed by remote host
Mar 07 13:48:53 el9.example.com sshd[3841]: Connection closed by xxx.xx.32.149 port 59312
Mar 07 13:48:58 el9.example.com systemd[1]: Stopping User Manager for UID 12884...

This might be interesting, but I really don't see anything that would suggest that the GNOME Shell session would be killed.

Can you try to start Tigervnc using systemd? This should be the way how to start it correctly. You can see how to configure it when you check "/usr/share/doc/tigervnc/HOWTO.md" or if you want it online you can find it here https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/HOWTO.md.

I have started the tigervnc service using systemd, in that case, my gnome session is working fine. However, I couldn't use it in production for reasons beyond the scope of this ticket. The default xstartup as created by the vncserver script produces the failing GNOME session.

Well, one should really use the systemd way of starting vnc server, because that way you get a proper session, while when you use the vncserver script, it is not a full session and you can see in the log that GNOME complains on many things, like DBus session not running. This might be the reason why it crashes. You can also see that you get a warning from using the vncserver script that is now considered deprecated.

I think I have found a workaround: The default xstartup file generated from vncserver contains this:

if [ -e /usr/bin/gnome-session ]; then
    vncserver -kill $DISPLAY
fi

If I comment this out, the vnc session will stay open, although the gnome-session program has exited, as the gnome shell and the other programs will continue to run.

(In reply to Götz Waschk from comment #10)
> I think I have found a workaround: The default xstartup file generated from
> vncserver contains this:
> 
> if [ -e /usr/bin/gnome-session ]; then
>     vncserver -kill $DISPLAY
> fi
> 
> If I comment this out, the vnc session will stay open, although the
> gnome-session program has exited, as the gnome shell and the other programs
> will continue to run.

This exists there, because it assumes that "/usr/bin/gnome-session" will run by default when GNOME is installed and that it will be blocking the script until user logs out. Once it logs out it would automatically kill the vnc session. All this is actually stated in the generated xstartup file if I'm not mistaken and one should really change it based on his needs. 

Maybe this assumption no longer applies and we cannot assume that gnome-session will block the script until user logs out so it might be better to remove this condition.

@rstrode, would you know if anything changed in this regard? I think this is what we actually came up with together years ago.

I suspect it may be trying to start a systemd --user based version of gnome-session and is falling over...

Götz can you try running:

echo gnome-session --builtin > ~/.Xclients
chmod +x ~/.Xclients

(and add back the vncserver -kill $DISPLAY to xstartup)

and see if that works?  That should force gnome-session to use the non-systemd based session.

Unfortunately, this didn't help. To verify, it started the binary with the correct option:
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
test       78658 16.0  0.0 446412 19516 pts/0    Sl   08:29   0:00 /usr/libexec/gnome-session-binary --builtin

But the program crashed and after closing the frowning face screen, the session was terminated by the xstartup script.

Created attachment 1949365 [details]
log file of the vnc session

This output is generated with gnome-session --builtin --debug

So looking at your logs, the issue is actually this:

Mar 07 13:48:30 el9.example.com org.gnome.SettingsDaemon.Subscription.desktop[3388]: Failed to start: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
...
Mar 07 13:48:30 el9.example.com gnome-session-binary[2878]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Subscription.desktop

So gnome-settings-daemon is trying to connect to subscription-manager and it's oddly not running and can't be activated.

being able to talk to subscription manager is a requirement of GNOME in RHEL 9, so failure to do so triggers the oh no dialog.  the oh no dialog forces a log out when it's dismissed.

Removing the "vncserver -kill $DISPLAY" prevents the session from dying completely on logout, so it's sort of half running half not.

is subscription-manager installed ?

Installing subscription-manager solved the issue for me, thanks.

thanks.

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 (gnome-settings-daemon and gnome-session bug fix and enhancement update), 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/RHBA-2023:6405