#906231 systemd: restarting systemd-logind causes power-button event to immediately shutdown cinnamon without asking

Package:
cinnamon
Source:
cinnamon
Description:
Innovative and comfortable desktop
Submitter:
Christoph Anton Mitterer
Date:
2026-08-17 19:23:03 UTC
Severity:
important
#906231#5
Date:
2018-08-15 17:58:51 UTC
From:
To:
Hi.

Since some systemd ugprade (unfortunately I don't remember which one it was exactly, cause I
hit the problem only rarely)... when systemd-logind has been restarted, e.g. by needrestart
after upgraded and I press the powerbutton, cinnamon shuts down immediately, without asking
what I want to do (suspend, hibernate, restart, etc.) as usual.

Could as well be a bug in cinnamon itself but since it occured after some systemd upgrade
I report it first here... please reassign if you think it's cinnamon specific.

severity important, as it can be quite problematic if one has e.g. written some longer text
file and just wants to suspend the systemd... and then everything is gone as the system
shuts down without any further request ;-)


Thanks,
Chris.
#906231#10
Date:
2018-08-15 19:02:13 UTC
From:
To:
Am 15.08.2018 um 19:58 schrieb Christoph Anton Mitterer:

Restarting logind is not supported, as X will immediately exit, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798097

needrestart should exclude logind from restart
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800718

I suppose what you are seeing is that Xorg exited.
#906231#15
Date:
2018-08-15 19:23:06 UTC
From:
To:
Hey Michael.
No,.. my X doesn't exit... the only thing that happens is, that when I
press the power button, no dialog that asks what should be done pops up
(as it does when logind wasn't restarted)


Cheers,
Chris.
#906231#20
Date:
2018-08-15 20:07:49 UTC
From:
To:
Am 15.08.2018 um 21:23 schrieb Christoph Anton Mitterer:

Are you sure then that logind is actually restarted? needrestart is not
supposed to restart logind (it's on its blacklist) and restart logind
will make Xorg abort?
#906231#25
Date:
2018-08-15 20:15:57 UTC
From:
To:
I just manually tried (actually logind was just a guess to be the cause
for the pop up not appearing... so I tried several services before)
I think it's not really on a forced blocklist but more on a "don't
restart per default)... I have set some option (so far at least) in
needrestart's conf... that makes everything default to no (i.e. nothing
is restarted unless I manually check it in the dialog...

I wasn't aware that one shouldn't restart logind, which is why I did it
always... but so far my X never restarted (it does when I restart e.g.
dbus).


Thanks,
Chris.
#906231#30
Date:
2018-08-15 20:33:25 UTC
From:
To:
Am 15.08.2018 um 22:15 schrieb Christoph Anton Mitterer:

If I restart logind via "systemctl restart systemd-logind", my X session
is terminated on sid.

I'm curious why that is not the case for you.
Are you using Wayland (not sure if cinnamon already uses it)?
#906231#35
Date:
2018-08-15 20:59:00 UTC
From:
To:
Nope... just tried it again (also sid)... cinnamon just continues to
run.
No, cinnamon has no wayland support (I think they do not even plan it).

Perhaps it's not X itself that gets restarted when logind is
restarted... but just something of GNOME... something which cinnamon
doesn't use (or uses differently)?
#906231#40
Date:
2018-08-15 21:20:20 UTC
From:
To:
Am 15.08.2018 um 22:59 schrieb Christoph Anton Mitterer:

Nope, it's Xorg.
Just try with a minimal WM like openbox.
#906231#50
Date:
2018-08-15 21:32:48 UTC
From:
To:
I'm afraid, I have no idea why mine doesn't restart ^^

Cheers,
Chris.
#906231#55
Date:
2018-08-15 23:05:59 UTC
From:
To:
Am 15.08.2018 um 23:32 schrieb Christoph Anton Mitterer:
My guess is, that the cinnamon component responsible for power
management not deal with the fact that logind goes away and does not
re-connect when it shows up again.

It's the responsibility of the DE to establish an inhibitor lock if it
wants to delay/block suspend/hibernate events.

As for the weird Xorg issue: My guess is, that your Xorg does not
actually use logind. I suppose you still start your X session with root
privileges and don't make use of logind to run unprivileged.
You could check your X logs in that regard.
Here Xorg runs like this:

michael   4953  2.0  1.0 646728 177012 tty2    Sl+  Aug15  25:10
/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority
-background none -noreset -keeptty -verbose 3
#906231#60
Date:
2018-08-15 23:12:28 UTC
From:
To:
Am 16.08.2018 um 01:05 schrieb Michael Biebl:

Fwiw, you can check that by calling systemd-inhibit
This should show you which process holds a blocking inhibitor for the
key events. Under GNOME you'll have

     Who: michael (UID 1000/michael, PID 5201/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: GNOME Shell (UID 1000/michael, PID 5036/gnome-shell)
    What: sleep
     Why: GNOME muss den Bildschirm sperren
    Mode: delay

Restart logind, then check logind again.
If the process is no longer listed, file a bug report against the binary
which was running that process.
#906231#65
Date:
2018-08-15 23:13:03 UTC
From:
To:
Control: reopen -1
Control: reassign -1 cinnamon 3.8.8-1
Well I reopened & reassigned it for now. Maybe the cinnamon maintainers
have some idea.
In fact it does run as root... I'm using lightdm... not sure if that
supports running it unprivileged or perhaps I have just some other
misconfiguration that it still runs via root!?


Best wishes,
Chris.
#906231#78
Date:
2018-08-15 23:14:35 UTC
From:
To:
Am 16.08.2018 um 01:12 schrieb Michael Biebl:

Check systemd-inhibit again, obviously...
#906231#83
Date:
2018-08-15 23:30:03 UTC
From:
To:
Thanks for the hints :-)

now before restarting logind the first time I had:
$ systemd-inhibit
     Who: UPower (UID 0/root, PID 3801/upowerd)
    What: sleep
     Why: Pause device polling
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 4019/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

2 inhibitors listed.


and afterwards, upower was gone


$ systemd-inhibit
     Who: NetworkManager (UID 0/root, PID 4019/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

1 inhibitors listed.


When I now restart upower.service it goes back into the list, but when
I now press the power button, I still get an immediate shutdown...


Thanks,
Chris.
#906231#88
Date:
2018-08-16 01:11:33 UTC
From:
To:
Am 16.08.2018 um 01:30 schrieb Christoph Anton Mitterer:

upower is a red herring.
Please restart your desktop session and then run systemd-inhibit.
#906231#93
Date:
2018-09-10 12:18:13 UTC
From:
To:
I can confirm that something broke somewhere after upgrade of systemd packages to v239 or v238.
I use LXQt and Lightdm. Restarting logind during upgrades never caused any problems until recently.
Now suspend authentication breaks, policykit auth is required on every attempt of suspending after logind restart.
#906231#98
Date:
2019-02-26 13:43:08 UTC
From:
To:
#906231#103
Date:
2026-08-17 19:21:23 UTC
From:
To:
This was a systemd bug, not a Cinnamon one, and it has been fixed
upstream long ago.

The desktop takes a `block` inhibitor lock on
`handle-power-key:handle-suspend-key:handle-hibernate-key`
(csd-media-keys); when that lock is
lost, logind falls back to its default `HandlePowerKey=poweroff` and
shuts down immediately,
which is the symptom reported here. Restarting logind used to drop those
inhibitors — see
https://github.com/systemd/systemd/issues/11825, fixed by
https://github.com/systemd/systemd/pull/13143, merged in July 2019 and
released in systemd v243.
Buster shipped 241 and was affected; bullseye and later are not.

Retested on recent unstable (cinnamon 6.6.9-1, cinnamon-settings-daemon
6.6.4-1, systemd 261.2-1,
lightdm, X11): after `systemctl restart systemd-logind` the session
survives, the inhibitor list
is unchanged, and pressing the power button brings up the usual dialog
instead of powering off.
logind logs "Power key pressed short." and takes no action, as it should.

Closing accordingly. Note that the polkit part mentioned later in this
log (authentication being
required again after a logind restart) is a separate matter, considered
by design upstream.