#1002832 cinnamon delays shutdown

Package:
cinnamon
Source:
cinnamon
Description:
Innovative and comfortable desktop
Submitter:
Jeffrey Ratcliffe
Date:
2026-08-16 11:37:03 UTC
Severity:
normal
#1002832#5
Date:
2021-12-29 16:15:35 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I worked normally with the PC

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I try to shutdown the PC.

   * What was the outcome of this action?

I get the error message: "A stop job is running for session 2 of user <user>"

The shutdown process then waits 90s before continuing.

sudo journalctl -b-1

shows the following entries:

Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Stopping timed out.
Killing.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7577
(cinnamon-launch) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7623
(gdbus) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Failed with result
'timeout'.

A workaround is to logout first, and then shutdown from the log-in screen.

   * What outcome did you expect instead?

The shutdown process to proceed immediately.

*** End of the template - remove these template lines ***

#1002832#10
Date:
2021-12-29 16:38:03 UTC
From:
To:
Il 29/12/2021 17:15, Jeffrey Ratcliffe ha scritto:
thanks for report, this issue was already reported by others users here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996668

I din't found the exact cause but on one testing vm where I repoduced it
the bug disappaired after 5.2 packages install, 5.2 packages are ready
for upload to experimental for weeks but I was unable to find someone
that can upload them:
https://lists.debian.org/debian-mentors/2021/12/msg00082.html

if you want do a fast test with them you can install the packages I did
for testing (on
http://debomatic-amd64.debian.net/distribution#dpr-cinnamon-unstable),
you can find istruction here:
https://lists.debian.org/debian-cinnamon/2021/12/msg00006.html

#1002832#15
Date:
2026-08-16 11:34:35 UTC
From:
To:
This issue was fixed upstream by commit 5c1137ec2 ("cinnamon-launcher: use
os.WIFEXITED to interpret the status code when cinnamon exits.",
2021-11-25).

The cause was in /usr/bin/cinnamon-launcher: the exit status returned by
os.waitpid() is an encoded wait status, not a plain exit code, but it was
checked with "if exit_status != 0". At the end of the session cinnamon
terminates normally, yet that check treated it as a crash, so the launcher
entered its crash-recovery path: it forked the metacity fallback session,
started the fallback helpers (polkit agent, nm-applet) and popped up the
"Cinnamon just crashed" dialog. As a result cinnamon-launcher kept running
inside session-N.scope, and systemd waited for its 90 seconds stop timeout
before SIGKILLing it - the "A stop job is running for session N of user X"
message reported here. This also explains why killing cinnamon-launcher by
hand, or logging out before shutting down, avoided the delay, and why no
crash or segfault was visible in the logs.

The fix is included upstream since 5.2.1, and in Debian since cinnamon
5.2.6-1 (experimental) and 5.2.7-2 (unstable, uploaded on 2022-01-26).
All currently supported suites therefore carry it: bookworm (5.6.x),
trixie (6.4.10) and unstable (6.6.9-1).

Closing this bug and #1002832, which was merged with it.

If anyone still runs into a similar shutdown or logout delay on a current
version, please do not reopen this bug: the cause described above is gone,
so the same symptom now would have a different root cause and needs to be
tracked separately. Please file a new report instead, including:

  - the exact versions of cinnamon and cinnamon-session;
  - the output of "journalctl -b -1" around the "A stop job is running"
    message, showing which processes are killed and in which scope/unit;
  - whether the delay also happens with a newly created user account;
  - whether logging out first and then shutting down from the login manager
    avoids it.

Thanks to everyone who reported and helped debugging this.