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

Im having the same issue too

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

The same thing happens under Ubuntu Gnome too.

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

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

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.

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

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

https://github.com/desrt/systemd-shim/commit/6c65a11321f

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

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?

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

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

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

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.

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...

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.

I pushed a cleaned up fix to https://github.com/desrt/systemd-shim/commit/b8f324dae5d13b54.

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

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!

Fine on saucy here with -proposed package

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

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.

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

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.

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.

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

Am I using the correct Unix command?

Well that was embarrassing... -p