RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2175675 - gnome session crashes if subscription-manager isn't installed
Summary: gnome session crashes if subscription-manager isn't installed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gnome-settings-daemon
Version: 9.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Tomas Pelka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-06 10:05 UTC by Götz Waschk
Modified: 2023-11-07 09:35 UTC (History)
8 users (show)

Fixed In Version: gnome-settings-daemon-40.0.1-13.el9 gnome-session-40.1.1-8.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-07 08:30:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
journalctl -b output (251.28 KB, text/plain)
2023-03-07 12:53 UTC, Götz Waschk
no flags Details
log file of the vnc session (158.70 KB, text/plain)
2023-03-09 14:24 UTC, Götz Waschk
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/rpms gnome-session merge_requests 11 0 None opened Add hard dependency on subscription-manager 2023-06-16 15:14:24 UTC
Gitlab redhat/centos-stream/rpms gnome-settings-daemon merge_requests 12 0 None opened Add hard dependency on subscription-manager 2023-05-04 18:43:19 UTC
Gitlab redhat/centos-stream/rpms gnome-settings-daemon merge_requests 13 0 None opened Revert hard dependency on subscription-manager since we're going to put it in gnome-session instead 2023-06-16 15:08:49 UTC
Red Hat Issue Tracker RHELPLAN-150716 0 None None None 2023-03-06 10:05:50 UTC
Red Hat Product Errata RHBA-2023:6405 0 None None None 2023-11-07 08:30:43 UTC

Description Götz Waschk 2023-03-06 10:05:17 UTC
Description of problem:
The GNOME session crashes if started from VNC.

Version-Release number of selected component (if applicable):
gnome-session-40.1.1-6.el9.x86_64

How reproducible:
always

Steps to Reproduce:
1. create a fresh user account
2. run a vncserver with default settings: vncserver :3
3. connect to vnc server with vncviewer localhost:3
4. click away the welcome screen
5. click an icon, e.g. nautilus or the gnome terminal button

Actual results:
the frowning face gnome crash screen is displayed

Expected results:
The application should start.

Additional info:
There was at least no segmentation fault involved, with ulimit -c unlimited no core file was produced.

Comment 1 Tomas Popela 2023-03-06 12:25:14 UTC
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`)?

Comment 2 Götz Waschk 2023-03-06 12:52:26 UTC
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

Comment 3 Tomas Popela 2023-03-06 13:35:54 UTC
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.

Comment 4 Götz Waschk 2023-03-06 13:52:02 UTC
I can reproduce it 100%. I'll get back to you as soon as I can reboot the machine.

Comment 5 Götz Waschk 2023-03-07 12:53:06 UTC
Created attachment 1948667 [details]
journalctl -b output

Comment 6 Tomas Popela 2023-03-07 13:03:55 UTC
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.

Comment 7 Jan Grulich 2023-03-07 13:30:43 UTC
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.

Comment 8 Götz Waschk 2023-03-07 14:13:16 UTC
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.

Comment 9 Jan Grulich 2023-03-07 14:19:56 UTC
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.

Comment 10 Götz Waschk 2023-03-08 11:14:24 UTC
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.

Comment 11 Jan Grulich 2023-03-08 11:30:33 UTC
(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.

Comment 12 Ray Strode [halfline] 2023-03-08 17:06:33 UTC
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.

Comment 13 Götz Waschk 2023-03-09 07:33:49 UTC
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.

Comment 14 Götz Waschk 2023-03-09 14:24:51 UTC
Created attachment 1949365 [details]
log file of the vnc session

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

Comment 15 Ray Strode [halfline] 2023-03-09 15:33:31 UTC
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 ?

Comment 17 Götz Waschk 2023-03-09 16:53:27 UTC
Installing subscription-manager solved the issue for me, thanks.

Comment 18 Ray Strode [halfline] 2023-03-09 16:55:51 UTC
thanks.

Comment 35 errata-xmlrpc 2023-11-07 08:30:37 UTC
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


Note You need to log in before you can comment on or make changes to this bug.