Shutdowns fail to finish if laptop lid is closed before completely shutdown

Bug #1211514 reported by Doug McMahon on 2013-08-12
54
This bug affects 12 people
Affects Status Importance Assigned to Milestone
systemd-shim (Ubuntu)
High
Unassigned
Saucy
High
Martin Pitt
Trusty
High
Unassigned

Bug Description

Only seen in a ubuntu (unity) session, others report gnome sessions

SRU INFORMATION
----------------

TEST CASE on laptop:
 - Shutdown machine from session indicator, close laptop lid right after selecting shutdown or reboot from pop up window.
 - What should happen: lid close gets ignored and machine should complete shutdown process
- What does happen: machine gets suspended until the laptop lid is re-opened, then it either completes the shutdown (if the lid close happened early enough), or hangs eternally

FIX: https://github.com/desrt/systemd-shim/commit/6c65a113 and https://github.com/desrt/systemd-shim/commit/b8f324dae5 (both are needed)

REGRESSION POTENTIAL: A broken systemd-shim can potentially completely prevent shutdown, reboot, suspend, hibernate. This code has been tested with all scenarios, with both doing suspend/lid close during normal operation, and during shutdown (at which point lid close is now ignored).

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: unity 7.1.0+13.10.20130812.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-1.4-generic 3.11.0-rc4
Uname: Linux 3.11.0-1-generic x86_64
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Mon Aug 12 17:01:09 2013
InstallationDate: Installed on 2013-08-07 (4 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130803)
MarkForUpload: True
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

Doug McMahon (mc3man) wrote :
James Ramsay (f-jack) wrote :

Im having the same issue too

Changed in unity (Ubuntu):
status: New → Confirmed
parmeshwar89 (parmeshwar89) wrote :

I have the same problem!
During shutdown if you close the lid, it does not get shutdown, I think it goes into sleep mode.

Baldrick (bheath-nz) wrote :

The same thing happens under Ubuntu Gnome too.

Doug McMahon (mc3man) on 2013-11-02
description: updated
tags: added: trusty
Doug McMahon (mc3man) wrote :

scorecard here
shutdown suspends when lid is closed before shutdown completes on -
unity/lightdm, unity/gdm, gnomes-hell/lightdm

shutdown does not suspend when lid is closed before shutdown completes -
gnome-shell/gdm

So adding lightdm & upstart, maybe someone can figure out as this flies in the face of any laptop & any Os I've ever used

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Steve Langasek (vorlon) wrote :

The GNOME stack should be handling the suspend suppression. If it's not, that seems to be an issue with yet another undocumented interface/assumption within the GNOME components.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) on 2013-11-05
affects: upstart → gnome-settings-daemon (Ubuntu)
Changed in unity (Ubuntu):
status: Confirmed → Invalid
importance: Undecided → Low
no longer affects: lightdm
no longer affects: unity (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Sebastien Bacher (seb128) wrote :

The issue is rather a logind one, that happens after session closing

affects: gnome-settings-daemon (Ubuntu) → systemd (Ubuntu)
Changed in systemd (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :
affects: systemd (Ubuntu) → systemd-shim (Ubuntu)
Changed in systemd-shim (Ubuntu):
status: Confirmed → Fix Committed
Martin Pitt (pitti) wrote :

I still get that issue even with the above git commit, so setting back to triaged.

Changed in systemd-shim (Ubuntu Trusty):
status: Fix Committed → Triaged
Martin Pitt (pitti) wrote :

I modified /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service as follows:

Exec=/bin/sh -c 'env G_DBUS_DEBUG=all annotate-output /usr/lib/x86_64-linux-gnu/systemd-shim >> /var/log/systemd-shim.log 2>&1'

This log file is the result. Apparently suspend is being called just fine, but I don't see any shutdown here. It seems the session indicator requests shutdown through something else than logind?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd-shim (Ubuntu Saucy):
status: New → Confirmed
Doug McMahon (mc3man) wrote :

Trust me, not a suggested fix as I don't know of these matters.
The one way I've found to get an expected shutdown with lid closed before shutdown completes in 14.04 is to uncomment & edit this line in /etc/systemd/logind.conf
#HandleLidSwitch=suspend
to
HandleLidSwitch=poweroff

Doug McMahon (mc3man) wrote :

It also seems that this works as well, which from a no noting perspective I'm more comfortable with
HandleLidSwitch=ignore

Martin Pitt (pitti) wrote :

I verified using dbus-monitor that the indicator/gnome-session calls systemd-shim for poweroff:

method call sender=:1.2 -> dest=org.freedesktop.systemd1 serial=160 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=StartUnit
   string "poweroff.target"
   string "replace-irreversibly"

So it looks like the current magic for preventing suspend during shutdown is not working due to something subtle. I'll do more in-depth debugging with verbose logs for everything.

Martin Pitt (pitti) wrote :
Download full text (3.2 KiB)

I now ran everything with D-BUS monitoring and GDBUS debugging in shim.

When selecting "Shutdown" from the indicator, on the session bus there's nothing surprising:

method call sender=:1.18 -> dest=:1.34 serial=53 path=/org/gnome/SessionManager/EndSessionDialog; interface=org
.gnome.SessionManager.EndSessionDialog; member=Open
method call sender=:1.34 -> dest=:1.13 serial=538 path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; member=Shutdown

gnome-session then calls to systemd for the actual shutdown on the system bus:

signal sender=:1.2 -> dest=(null destination) serial=156 path=/org/freedesktop/login1; interface=org.freedeskto
p.login1.Manager; member=PrepareForShutdown
   boolean true

method call sender=:1.2 -> dest=org.freedesktop.systemd1 serial=165 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=StartUnit
   string "poweroff.target"
   string "replace-irreversibly"

Notably this is the only method call to systemd-shim in the whole process (I don't see a suspend.target call!), and there are no calls to UPower or logind.

However, there is no corresponding entry in systemd-shim's debug output. Instead, I only see:

18:06:24 O: interface -> 'org.freedesktop.systemd1.Manager'
18:06:24 O: member -> 'StartUnit'
18:06:24 O: destination -> 'org.freedesktop.systemd1'
18:06:24 O: sender -> ':1.2'
18:06:24 O: signature -> signature 'ss'
18:06:24 O: Body: ('suspend.target', 'replace-irreversibly')

so something (presumably logind) indeed calls systemd-shim's suspend target when I close the lid. Conversely, I don't see *that* call in the system D-BUS monitor.

However, monitoring D-BUS during shutdown is a rather wonky business in the first place, as during shutdown the system D-BUS itself is being killed. So I figure it wasn't actually running any more, or being shut down when I closed the lid, and I missed logind's suspend call to systemd-shim.

The main oddity which points out why this happens is that systemd-shim does *not* stay running as one would expect:

18:28:17 I: Started /usr/lib/x86_64-linux-gnu/systemd-shim
18:28:17 E:
18:28:17 E: ** (process:3919): WARNING **: going into in_shutdown mode now
[...] # ^ I manually added that warning for debugging the in_shutdown flag
18:28:18 O: GDBus-debug:Call:
18:28:18 O: >>>> ASYNC org.freedesktop.DBus.RequestName()
[...] # this does not get very far:
18:28:18 O: GDBus-debug:Transport:
18:28:18 O: <<<< READ 16 bytes of message with serial 3 and
18:28:18 O: size 189 to offset 0 from a GSocketInputStream
Terminated

and immediately afterwards:
18:28:19 I: Started /usr/lib/x86_64-linux-gnu/systemd-shim
[...] # so at that point we definitively lost the call to poweroff.target and the in_shutdown flag.
18:28:19 O: GDBus-debug:Message:
[...]
18:28:19 O: Body: ('suspend.target', 'replace-irreversibly')
   # this would then actually be executed as it's a fresh instance.

So as far as I can see, we need to keep systemd-shim alive even if the system D-BUS is being shut down. It still seems to be alive enough to spawn new requests, but it already *seems* to kill existing instances; at least that's how I interpret t...

Read more...

Martin Pitt (pitti) wrote :
Martin Pitt (pitti) wrote :

So the problem is that during shutdown we SIGTERM everything that's running. Shield systemd-shim against that with http://paste.ubuntu.com/6406628/

I tested this two times, and it works.

Changed in systemd-shim (Ubuntu Trusty):
status: Triaged → In Progress
Martin Pitt (pitti) on 2013-11-13
Changed in systemd-shim (Ubuntu Trusty):
milestone: none → ubuntu-13.11
Martin Pitt (pitti) on 2013-11-13
Changed in systemd-shim (Ubuntu Trusty):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :
Changed in systemd-shim (Ubuntu Trusty):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Fix Committed
description: updated
Martin Pitt (pitti) on 2013-11-14
Changed in systemd-shim (Ubuntu Saucy):
status: Confirmed → In Progress
assignee: nobody → Martin Pitt (pitti)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd-shim - 5-0ubuntu1

---------------
systemd-shim (5-0ubuntu1) trusty; urgency=low

  * New upstream release:
    - Write a sendsigs.omit.d file to prevent upstart from killing us during
      shutdown. That's the other half of preventing suspends during shutdown.
      (LP: #1211514)
  * Update debian/copyright and debian/watch for new upstream address.
 -- Martin Pitt <email address hidden> Thu, 14 Nov 2013 18:44:47 +0100

Changed in systemd-shim (Ubuntu Trusty):
status: Fix Committed → Fix Released
Changed in systemd-shim (Ubuntu Saucy):
assignee: Martin Pitt (pitti) → nobody
Martin Pitt (pitti) on 2013-11-26
Changed in systemd-shim (Ubuntu Saucy):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

I uploaded a saucy SRU for this, in the SRU team review queue now.

Hello Doug, or anyone else affected,

Accepted systemd-shim into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/systemd-shim/6-0ubuntu0.13.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd-shim (Ubuntu Saucy):
status: In Progress → Fix Committed
tags: added: verification-needed
Doug McMahon (mc3man) wrote :

Fine on saucy here with -proposed package

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd-shim - 6-0ubuntu0.13.10

---------------
systemd-shim (6-0ubuntu0.13.10) saucy-proposed; urgency=low

  * New upstream bug fix release:
    - Write a sendsigs.omit.d file to prevent upstart from killing us during
      shutdown. That's the other half of preventing suspends during shutdown.
      (LP: #1211514)
    - Flush the right bus (system, not session), to address another case of
      "PrepareForSleep signal is missing" which breaks networking after
      resuming. (helps some people in LP: #1252121)
 -- Martin Pitt <email address hidden> Tue, 10 Dec 2013 10:59:08 +0100

Changed in systemd-shim (Ubuntu Saucy):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for systemd-shim has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

jeremy-list (quick-dudley) wrote :

The update that was supposed to fix this either isn't in the trusty repository yet or doesn't work.

Andy Carver (andycarver) wrote :

FIXED

modify

logind.conf

sudo gedit /etc/systemd/logind.conf

Find the line #HandleLidSwitch=suspend, remove the # and change it to:

HandleLidSwitch=ignore

Save the file with the same name

CTRL x

Reboot.

Sudo reboot now

You are welcome.

Andy Carver (andycarver) wrote :

It appears it to be a partial workaround. Shut down command via ssh halted. Reboot command via ssh appears successful.

It may have been because of a zombie. They eat celeron brains for breakfast.

I'll confirm when I can.

Andy Carver (andycarver) wrote :

Update.
Ignored all lid items in file
Shuts down via VNC..

Am I using the correct Unix command?

Andy Carver (andycarver) wrote :

Well that was embarrassing... -p

Changed in systemd-shim (Ubuntu Saucy):
importance: Undecided → High
Changed in systemd-shim (Ubuntu Trusty):
milestone: ubuntu-13.11 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers