System doesn't power off when shutting down

[Iain Lane]

1. Open the session indicator (cog in top-right)
2. Shut Down...
3. Shut Down
4. The monitors go blank
5. The system doesn't power off (waited > 5 minutes)

Things which do work

 - poweroff -f
 - Changing to a debug shell and shutting down using login1.Manager PowerOff

I can't use the system-shutdown/ functionality since shutdown doesn't get that far. I can't SSH in since network is down. I can't switch VT when it's in this state so I'm not able to interact with the system. I can't see anything on the monitors since they are turned off.

Any tips on how to get useful debugging information? I'll attach journalctl from the previous boot but the last message is the journal shutting down so it's not that useful I don't think. Also syslog.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-4ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0
Uname: Linux 3.19.0-7-generic x86_64
ApportVersion: 2.16.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Mar 3 12:57:33 2015
InstallationDate: Installed on 2012-10-07 (876 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007)
MachineType: System manufacturer System Product Name
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-7-generic root=UUID=980689ca-e7d9-4a99-8230-33b8b6e917cd ro nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw systemd.debug-shell nomdmonddf nomdmonisw
SourcePackage: systemd
UpgradeStatus: Upgraded to vivid on 2013-05-07 (665 days ago)
dmi.bios.date: 08/17/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1201
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8Z77-V LX
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1201:bd08/17/2012:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8Z77-VLX:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Launchpad Janitor (janitor)]

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

[Iain Lane (laney)]

laney@raleigh> gdbus call --system --dest org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors
([('handle-lid-switch', 'laney', 'Multiple displays attached', 'block', uint32 1000, uint32 2504), ('sleep', 'Unity Lockscreen', 'Unity wants to lock screen before suspending.', 'delay', 1000, 2809), ('shutdown:sleep', 'Telepathy', 'Disconnecting IM accounts before suspend/shutdown...', 'delay', 1000, 2693), ('sleep', 'NetworkManager', 'NetworkManager needs to turn off networks', 'delay', 0, 1367), ('sleep', 'laney', 'GNOME needs to lock the screen', 'delay', 1000, 2504), ('handle-power-key:handle-suspend-key:handle-hibernate-key', 'laney', 'GNOME handling keypresses', 'block', 1000, 2504)],)

[Iain Lane (laney)]

Also calling PowerOff directly when the session is open (Active=yes) still hangs, leading me to believe that the problem is beneath the gnome-session layer.

[dino99 (9d9)]

Can confirm that issue on Vivid i386, closing a gnome-shell session using the top cog 'shutdown' choice.
But it is only happening from time to time (~1/10):
  - most of the time it takes a few seconds to shutdown: but the system is always powered on (should not be)
  - when it fails to shutdown, a hard power off is needed. Trying a hard reset with the button also fails.
  - next first cold boot always ends with a kernel panic
  - but nothing usefull is logged

[dino99 (9d9)]

note2 : i'm wondering if the 'shutdown' choice deals as it might with the logout session before shuting down.

[Iain Lane (laney)]

Sounds similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763028 to me, although AFAIK rebooting is fine in my case.

[Iain Lane (laney)]

Also magic sysrq+b works to reboot when it is hanging.

[Iain Lane (laney)]

In fact I was wrong about restarting; I just 'sudo reboot' and it's hanging.

[Martin Pitt (pitti)]

So the journal goes to the "bitter end" when it's supposed to turn off the computer, so nothing really useful there. I have no immediate idea here, just perhaps some debugging tips.

I also noticed that sometimes shutting down causes the screen to freeze/go black, I attributed that to a graphics driver bug when shutting down lightdm/X.org (I sometimes get a similar effect when switching users). Does this also happen if you switch to a VT before shutting down? You can use sudo systemctl poweroff, or sudo poweroff (should be by and large the same).

Another thing is, perhaps it shows some more things if you boot with "debug"? that'll activate kernel debug messages too.

[Iain Lane (laney)]

Hi Martin,

On Wed, Mar 04, 2015 at 03:36:46PM -0000, Martin Pitt wrote:
> So the journal goes to the "bitter end" when it's supposed to turn off
> the computer, so nothing really useful there. I have no immediate idea
> here, just perhaps some debugging tips.
>
> I also noticed that sometimes shutting down causes the screen to
> freeze/go black, I attributed that to a graphics driver bug when
> shutting down lightdm/X.org (I sometimes get a similar effect when
> switching users). Does this also happen if you switch to a VT before
> shutting down? You can use sudo systemctl poweroff, or sudo poweroff
> (should be by and large the same).
>
> Another thing is, perhaps it shows some more things if you boot with
> "debug"? that'll activate kernel debug messages too.

Here's a 'debug' (and 'systemd.log_level=debug') log. I'm afraid the
last thing it shows is rsyslog shutting down which isn't really all too
helpful. :(

Would it help to remove "Conflicts=shutdown.target" from syslog.socket?

poweroff from a vt (as opposed to a debug shell, so there should have
been an Active=yes session) worked.

Using the indicator from unity-greeter did not work.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Martin Pitt (pitti)]

Indeed rsyslog will stop too early. You might have better luck with actually looking at the journal from the last boot, with

  sudo journalctl -b -1 > /tmp/journal.txt

and attaching that.

> poweroff from a vt (as opposed to a debug shell, so there should have been an Active=yes session) worked.

poweroff not working from a debug shell is worrying. The debug shell runs as root, and poweroff is supposed to work fine there. What happens exactly?

[Iain Lane (laney)]

On Sun, Mar 08, 2015 at 10:33:40AM -0000, Martin Pitt wrote:
> Indeed rsyslog will stop too early. You might have better luck with
> actually looking at the journal from the last boot, with
>
> sudo journalctl -b -1 > /tmp/journal.txt
>
> and attaching that.

I think one of my previous attachments is from journalctl --- anyway,
the journal is also stopped too early. I was suggesting modifying one of the
jobs so that {journal,rsyslog} stays up as long as possible.

>
> > poweroff from a vt (as opposed to a debug shell, so there should have
> been an Active=yes session) worked.
>
> poweroff not working from a debug shell is worrying. The debug shell
> runs as root, and poweroff is supposed to work fine there. What happens
> exactly?

It *does* work from a debug shell, which means that it does *not*
reproduce this bug there. It also *does* work from a vt, so having an
Active session isn't enough, there's something in the user session
causing this problem.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Martin Pitt (pitti)]

Ah, thanks. I misunderstood you then.

Can you say with certain confidence that the kernel/graphics driver crash (that's what it seems to be) only happens with systemd, but not with upstart? Perhaps there's some difference in how we shut down X.org/lightdm under either. Can you reliably switch users or just start/stop your session under upstart and systemd? (The latter is the part that causes graphics driver/kernel crashes on my machine occasionally, but it doesn't seem init specific)

[Iain Lane (laney)]

On Sun, Mar 08, 2015 at 06:50:58PM -0000, Martin Pitt wrote:
> Ah, thanks. I misunderstood you then.
>
> Can you say with certain confidence that the kernel/graphics driver
> crash (that's what it seems to be) only happens with systemd, but not
> with upstart? Perhaps there's some difference in how we shut down
> X.org/lightdm under either. Can you reliably switch users or just
> start/stop your session under upstart and systemd? (The latter is the
> part that causes graphics driver/kernel crashes on my machine
> occasionally, but it doesn't seem init specific)

OK, just checked with upstart - poweroff is fine there.

Seems session start is fine too: I just tried 10 times under both and
that works too.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Martin Pitt (pitti)]

Iain, you said on IRC that you got a clean shutdown with https://launchpad.net/ubuntu/+source/dbus/1.8.12-1ubuntu5 . Can you confirm that this is stable now with several shutdowns? If so, this would then be a duplicate of bug 1438612.

[Iain Lane (laney)]

Seems so - thanks!