Bug 2402621

Created attachment 2109083 [details]
File: proc_pid_status

Created attachment 2109084 [details]
File: maps

Created attachment 2109085 [details]
File: limits

Created attachment 2109086 [details]
File: environ

Created attachment 2109087 [details]
File: open_fds

Created attachment 2109088 [details]
File: mountinfo

Created attachment 2109089 [details]
File: os_info

Created attachment 2109090 [details]
File: cpuinfo

Created attachment 2109091 [details]
File: core_backtrace

Created attachment 2109092 [details]
File: dso_list

Created attachment 2109093 [details]
File: backtrace

Bug reports for this component on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved. This issue should only be kept open if it:

1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

Thank you!

Reopen, this might actually be a selinux/etc problem as I'm seeing:

Oct 16 12:30:03 localhost-live systemd[2581]: selinux: avc:  denied  { status } for auid=n/a uid=60578 gid=978 path="/usr/lib/systemd/user/graphical-session-pre.target" cmdline="/usr/libexec/gnome-session-init-worker gnome-initial-setup" function="reply_unit_path" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0
Oct 16 12:30:03 localhost-live systemd[2581]: SELinux access check scon=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcon=system_u:object_r:systemd_unit_file_t:s0 tclass=service perm=status state=enforcing function=reply_unit_path path=/usr/lib/systemd/user/graphical-session-pre.target cmdline=/usr/libexec/gnome-session-init-worker gnome-initial-setup: Permission denied

and then a bit later:

Oct 16 12:30:03 localhost-live systemd[2581]: Stopped gnome-initial-setup.service - GNOME Initial Setup.
Oct 16 12:30:03 localhost-live systemd[2581]: gnome-initial-setup.service: Consumed 19.808s CPU time, 629.2M memory peak.
Oct 16 12:30:03 localhost-live systemd[2581]: Stopped target gnome-session - GNOME Session (session: gnome-initial-setup).
Oct 16 12:30:04 localhost-live gnome-shell[2647]: Failed to store screen time limits data: Error opening file “/run/gdm/home/gnome-initial-setup/.local/share/gnome-shell/session-active-history.json”: No such file or directory
Oct 16 12:30:04 localhost-live systemd[2581]: Stopping gnome-session-manager - GNOME Session Manager (session: gnome-initial-setup)...
Oct 16 12:30:49 localhost-live systemd[2581]: gnome-session-manager: State 'stop-sigterm' timed out. Aborting.
Oct 16 12:30:49 localhost-live systemd[2581]: gnome-session-manager: Killing process 2623 (gnome-session-s) with signal SIGABRT.
Oct 16 12:30:50 localhost-live systemd[2581]: gnome-session-manager: Main process exited, code=dumped, status=6/ABRT
Oct 16 12:30:50 localhost-live systemd[2581]: gnome-session-manager: Failed with result 'timeout'.
Oct 16 12:30:50 localhost-live systemd[2581]: Stopped gnome-session-manager - GNOME Session Manager (session: gnome-initial-setup).
Oct 16 12:30:50 localhost-live systemd[2581]: gnome-session-manager: Triggering OnFailure= dependencies.

*** Bug 2388184 has been marked as a duplicate of this bug. ***

*** Bug 2404593 has been marked as a duplicate of this bug. ***

Trolling bugzilla there are 3 other reports which look the same, including on x86 and with F42.

And yes, i just duplicated it on F43 1.4 RC with x86 in a virt-manager vm. Default settings. This is likely at least part of that initial lag when gnome is initially starting.

EX: virt-manager->new vm->local install media (use fedora-workstation.iso)
basically default everything.
reboot after install
walk through initial setup, turn off location services, click a timezone, enable 3rd party repositories.
Wait a minute or two after the desktop appears, there is a corefile from gnome-session.

Proposed as a Blocker for 43-final by Fedora user jlinton using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#SELinux_and_crash_notifications

Jeremy, what exactly is the consequence of this bug? Do you see anything crash, does your user session aborts? Or is there no harmful effect, just a silent crash in the background? Do you see any notification for that crash (perhaps from ABRT?). The cited criterion says "there must be no notification", it doesn't mean there must be no crash or denial (as long as they're silent and doesn't have important negative effects). Thanks.

(In reply to Jeremy Linton from comment #17)
> EX: virt-manager->new vm->local install media (use fedora-workstation.iso)
> basically default everything.
> reboot after install
> walk through initial setup, turn off location services, click a timezone,
> enable 3rd party repositories.
> Wait a minute or two after the desktop appears, there is a corefile from
> gnome-session.

I reproduced this with F43 Workstation RC 1.4. There's the AVC and gnome-session-service crash. However, no notification ever popped up. ABRT processed it and shows it up in System tab, but didn't show any popup.

"Opps looks like a problem occurred" 

I'm guessing you didn't have sufficient permissions to see abrt notifications that wern't generated by your user id.

This by itself is probably a pretty large user interface bug as any crashing system services/etc simply get hidden from the default user.

I think this is the bug I'm seeing on the Pinebook Pro which is stopping the UX popping up all together.

(In reply to Jeremy Linton from comment #21)
> I'm guessing you didn't have sufficient permissions to see abrt
> notifications that wern't generated by your user id.

Have you done any local modifications? I'm talking about the default state after F43 Workstation installation and creating the default user (placed in the wheel group).

At least for me it's vanilla GNOME with a single user created by the initial setup process

The easy way to see it, is just to set a root password and login with that.

I think I can reproduce this when I install a fresh installation of Fedora Workstation 43. The crash can be seen in journalctl and is reported by Abrt, however the system remains fully usable. I reported the bug through Abrt but I cannot see it updated here, so I am going to add my journal.log to this bug.

Created attachment 2110239 [details]
Journalctl logs from the affected machine

There are two things here:
1) the crash
2) the blocker proposal

The blocker proposal is only valid if you see an error notification during your first login with the out-of-the-box default settings.

Have you seen a notification, Lukas?

I'm not really sure https://bugzilla.redhat.com/show_bug.cgi?id=2388184 is a dupe of this. The backtrace is pretty generic, as best as I can understand it, and the description of the circumstances doesn't seem similar.

As we suspect Peter's pinebook issue may not be caused by the g-i-s crash - at least not as it's reported in this bug report - we've filed https://bugzilla.redhat.com/show_bug.cgi?id=2405144 to track that case separately for now. If the two really do turn out to be the same bug, we can always close it as a dupe later.

AGREED Delayed Decision (Punt)

Discussed at the blocker review meeting on 20th Oct. 2025

We didn't reach a clear consensus on this with the folks present in the meeting. vote currently stands at +2 / -4. We have, for now, filed a separate bug for Peter Robinson's Pinebook Pro issue - https://bugzilla.redhat.com/show_bug.cgi?id=2405144 - and we're awaiting further details on that.

https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-10-20/f43-blocker-review.2025-10-20-16.02.html

Did we actually confirm the SELinux denial causes the crash? It should be relatively simple to check: do the first boot with enforcing=0 .

selinux=0 does not appear to fix the problem on aarch64.

The only denial I can find in the journal is

Oct 20 15:58:28 localhost-live systemd[2175]: Reached target gnome-session-x11-services.target - GNOME session X11 services.
Oct 20 15:58:28 localhost-live pcscd[1678]: 00000000 ../src/auth.c:166:IsClientAuthorized() Process 2561 (user: 981) is NOT authorized for action: access_pcsc
Oct 20 15:58:28 localhost-live pcscd[1678]: 00000121 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
Oct 20 15:58:28 localhost-live systemd[2175]: Starting org.gnome.SettingsDaemon.XSettings.service - GNOME XSettings service...
Oct 20 15:58:28 localhost-live gnome-shell[2320]: GNOME Shell started at Mon Oct 20 2025 15:58:25 GMT+0200 (Central European Summer Time)
Oct 20 15:58:28 localhost-live gnome-shell[2320]: Registering session with GDM
Oct 20 15:58:28 localhost-live systemd[1305]: Stopped gnome-session-monitor.service - Monitor Session leader for GNOME Session.   
Oct 20 15:58:28 localhost-live systemd[1305]: selinux: avc:  denied  { status } for auid=n/a uid=60578 gid=977 path="/usr/lib/systemd/user/graphical-session-pre.target" cmdline="/usr/libexec/gnome-session-init-worker gnome-initial-setup" function="reply_unit_path" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0
Oct 20 15:58:28 localhost-live systemd[1305]: SELinux access check scon=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcon=system_u:object_r:systemd_unit_file_t:s0 tclass=service perm=status state=enforcing function=reply_unit_path path=/usr/lib/systemd/user/graphical-session-pre.target cmdline=/usr/libexec/gnome-session-init-worker gnome-initial-setup: Permission denied
Oct 20 15:58:28 localhost-live gnome-session-i[1340]: Could not get unit for graphical-session-pre.target: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: SELinux policy denies access: Permission denied
Oct 20 15:58:28 localhost-live systemd[1305]: Stopped target gnome-session-wayland - GNOME Wayland Session (session: gnome-initial-setup).

Possible solution is to label /usr/lib/systemd/user/graphical-session-pre.target similar to

modules/services/xserver.fc:/usr/lib/systemd/user/.*gnome.*\.(service|target)           --      gen_context(system_u:object_r:xdm_unit_file_t,s0)
modules/services/xserver.fc:/usr/lib/systemd/user/plasma-.*\.(service|target)           --      gen_context(system_u:object_r:xdm_unit_file_t,s0)

see:

f44# sesearch -A -s xdm_t -t systemd_unit_file_t -c service -p status
f44# sesearch -A -s xdm_t -t xdm_unit_file_t -c service -p status
allow xdm_t xdm_unit_file_t:service { start status };

I cannot tell though if it has the power to resolve any of the reported problems.

It looks to me like what's happening here is basically that gnome-session-manager sends gnome-session-service a SIGTERM, which causes gnome-session-service to attempt some kind of "log out" operation, but that fails, so gnome-session-service doesn't actually terminate. 45 seconds later gnome-session-manager notices gnome-session-service hasn't gone away, and sends it a SIGABRT instead:

Oct 23 10:33:16 fedora systemd[1685]: Stopping gnome-session-manager - GNOME Session Manager (session: gnome-initial-setup)...
Oct 23 10:33:16 fedora gnome-session-service[1743]: Failed to log out: Logout has been locked down
Oct 23 10:34:02 fedora systemd[1685]: gnome-session-manager: State 'stop-sigterm' timed out. Aborting.
Oct 23 10:34:02 fedora audit[1743]: ANOM_ABEND auid=60578 uid=60578 gid=977 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1743 comm="gnome-session-s" exe="/usr/libexec/gnome-session-service" sig=6 res=1
Oct 23 10:34:02 fedora systemd[1685]: gnome-session-manager: Killing process 1743 (gnome-session-s) with signal SIGABRT.

and that's the thing we track as a 'crash':

Oct 23 10:34:02 fedora systemd-coredump[4635]: Process 1743 (gnome-session-s) of user 60578 terminated abnormally with signal 6/ABRT, processing...
Oct 23 10:34:02 fedora systemd-coredump[4636]: Process 1743 (gnome-session-s) of user 60578 dumped core.

etc. etc.

Discussed in the 2025-10-23 Fedora 43 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-10-23/f43-final-go-no-go-meeting.2025-10-23-17.01.html . Rejected as a blocker on the basis there's no solid evidence this causes any practical consequences that violate any release criteria; it seems to just be a relatively harmless 'crash' on teardown of the g-i-s environment which is only visible in the journal, coredumpctl or gnome-abrt 'system' view.

hmm, although, that "Failed to log out: Logout has been locked down" message looks like it really is just a message...the code execution should continue. It's at https://gitlab.gnome.org/GNOME/gnome-session/-/blob/main/gnome-session/service-main.c?ref_type=heads#L86 , and that `term_or_int_signal_cb` function looks like it should still complete after that message is logged. So, I'm not sure why the process isn't going away?

ah, hmm, I think the `gsm_manager_logout` call is intended to ultimately cause the process to exit...and the log message is printed if that call doesn't work. I wonder why logout is locked down at this point...and when this started happening...

(In reply to Adam Williamson from comment #38)
> I wonder why logout is locked down at this point...and when
> this started happening...

Educated guess: systemd inhibitor, systemd 257

Not sure whether the machine was in the process of entering suspend or resume, or possibly trying to log in to GDM.


reporter:       libreport-2.17.15
type:           CCpp
reason:         gnome-session-service killed by SIGABRT
journald_cursor: s=e6d6609fd76342fbb43520dc88447602;i=d0c;b=2684fdae751047cb906b98c1b2fdacc0;m=792bf89;t=642796054c50e;x=254456f0bfc388b8
executable:     /usr/libexec/gnome-session-service
cmdline:        /usr/libexec/gnome-session-service --session=gnome-initial-setup
cgroup:         0::/user.slice/user-60578.slice/user/app.slice/app-gnome\x2dsession\x2dmanager.slice/gnome-session-manager
rootdir:        /
uid:            60578
kernel:         6.17.1-300.fc43.x86_64
package:        gnome-session-49.1-1.fc43
runlevel:       /bin/sh: line 1: runlevel: command not found
backtrace_rating: 4
crash_function: __syscall_cancel_arch
comment:        Not sure whether the machine was in the process of entering suspend or resume, or possibly trying to log in to GDM.