different vm, same result.

Mar 26 21:29:59 vbox-f42 gnome-shell[2226]: endSessionDialog: No XDG_SESSION_ID, fetched from logind: 2
Mar 26 21:30:04 vbox-f42 gnome-session-binary[2148]: Entering running state
Mar 26 21:30:04 vbox-f42 gnome-shell[2226]: Gio.IOErrorEnum: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Vorgang wurde abgebrochen
                                            
                                            Stack trace:
                                              asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
                                              @resource:///org/gnome/shell/ui/init.js:21:20


happy to provide a better stack trace if someone tells me how to.

Proposed as a Blocker and Freeze Exception for 42-final by Fedora user augenauf using the blocker tracking app because:

 couldnt find a criterion that is violated, still nominating this as blocker bug as one can expect the system to shutdown from DE.

Hmmm I’ll keep an eye on this but so far cannot yet repro this.

I experienced this at least once but was able to first log out, then shutdown. Lately I've been able to shutdown directly again (on a fully updated F42).

What kind of VM, specifically? qemu/kvm? virtualbox? vmware? something else?

this vm is in virtualbox on a W11 host.

I was able to reproduce the bug today again with a fully updated F42.

`gnome-session-inhibit -l` said: "No inhibitors".

This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/.

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!

I have been unable to reproduce this in QEMU, Hyper-V or bare metal using the latest branched beta ISO.

Me too, not able to reproduce this on baremetal or qemu + virt-manager

Yesterday, I ran my F42 QEMU guest twice. The first time I was unable to shutdown directly from the "Power Off..." menu item, but was able to log out and then power off from the GDM screen. The second time I was able to power off directly from my logged in session. If I'm unable to power off directly again, what info/logs should I provide?

Report to the upstream bug please: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8296

If you log out first, can you power off from the GDM screen (as I've been able to whenever I've seen this)? If not, my problem may be different.

Oh, heh, I've actually been seeing this all F42 cycle but I just got used to it and didn't think about it when this report came in. I just got used to closing gedit before trying to restart/shut down...

Updating the upstream issue link.

I never use gedit so I was a little confused by the title, it definitely doesn't require that.

Although I may have done things like try to report an SELinux bug and had a graphical window come up which may have been gedit. But I don't think I did that every time I saw the bug. Will keep an eye on it.

Discussed during the 2025-03-31 blocker review meeting [1]:

* AGREED: 2355033 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - after some discussion of the details behind this bug, we're not sure whether to block on it. The worst case is when something not tracked by GNOME is inhibiting shutdown; in this case, shutdown fails without explanation. But that will not usually be the case, and in at least some cases, the new behaviour is probably better than the old behaviour (e.g. it wasn't good that you could happily shut down while a package install operation was happening outside of GNOME). we will punt this to try and investigate specific triggers to aid in deciding whether to block. It's clearly desirable to improve this behaviour during freeze if we can, though, so this is accepted FE.

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-31/f42-blocker-review.2025-03-31-16.01.log.html

If it matters, I'm getting stuff like this:
-----
type=AVC msg=audit(1743815403.976:153): avc:  denied  { getattr } for  pid=1167 comm="gnome-shell" path="/run/systemd/inhibit/4.ref" dev="tmpfs" ino=3196 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
-----

Which translates to:
-----
require {
	type xdm_t;
	type systemd_logind_inhibit_var_run_t;
	class fifo_file getattr;
}

#============= xdm_t ==============
allow xdm_t systemd_logind_inhibit_var_run_t:fifo_file getattr;
-----

After putting selinux into permissive mode, suspend works on my T450s. Just FYI.

Bojan, that sounds like a different bug, please file it against selinux-policy. Thanks!

(In reply to Kamil Páral from comment #19)
> Bojan, that sounds like a different bug, please file it against
> selinux-policy. Thanks!

Thanks. Already filed here: https://github.com/fedora-selinux/selinux-policy/issues/2624

Discussed during the 2025-04-07 blocker review meeting [1]:

* AGREED: 2355033 - Rejected FinalBlocker - This is a conditional violation of our poweroff criterion. We haven't found evidence that it would happen too frequently or in too many use cases. For that reason, we reject it as a final blocker. If there's new evidence that it's happening much more often, we can reconsider the blocker vote.

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-04-07/f42-blocker-review.2025-04-07-16.01.log.html

The upstream fix is in gnome-session, so lets move this

https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/119

Am I understanding right that the gnome-session MR would just restore previous behaviour? i.e. we'd happily just go ahead and shutdown if e.g. an RPM transaction was running on a VT, without even warning about it? If so, that doesn't seem *awesome*...longer term, is there a plan to improve it? Or am I misunderstanding?

It doesn't restore previous behavior. With the fix, gnome-session only drops its own inhibitors. Other inhibitors that are set up via the low-level systemd API are not touched; systemd v257 and newer will continue enforce them (silently, but that's another bug: https://gitlab.gnome.org/GNOME/gnome-session/-/issues/145).

gnome-session dropping its inhibitors is fine for two reasons. First, it only happens after the user is prompted, shown a list of inhibitors, and confirms shutdown anyway. Second, things like RPM shouldn't be using gnome-session inhibitors anyway. According to the API docs:

> Applications should not expect that they will always be able to block the action. In most cases, users will be given the option to force the action to take place

So, if you want to make sure that an inhibitor will be enforced, it must be a low-level systemd inhibitor.

(and on older versions of systemd, gnome-session's inhibitor was ignored anyway, no matter what we do... That's what caused this bug in the first place: before v257 the inhibitor was ignored and shutdown could continue, but after v257 systemd started enforcing it and it became impossible to shut down)