After upgrading to debian jessie my dated desktop system no longer powers off reliably (/sbin/poweroff - via systemctl on tty1). Instead, it shuts down, pauses and reboots and only powers off if I press the power-button. I tried various recommendations like acpi=force playing with bios settings, adding nouveau.modeset=0 and many more.

The only thing I found so far, is that not starting a graphical session seems to "fix" the problem. My Xsession is a simple .xsession file, there is no session manager involved (afaik) and all I do is start a number of programs. When I strip this file down to just an xterm or I do not log in at all, the system powers down.

I tried to uncomment more programs in my .xsession file in the hope of finding a culprit, but this did not lead to a conclusion. There seems to be some randomness involved. I am sure than none of my programs are still runnig at the time I issue the poweroff because I kill them all (uncluding a user systemd which was started by I-dont-know-who)

In the last messages before it reboots I see

System wakeup enabled by ACPI
Preparing to enter systel sleep state 5
GPU lockup - switching to software fbcon

But I see the same messages when it does poweroff (not 100% sure, because they are visible only for a short moment then)

Also I notice that in the bad cases, there are long pauses in the shutdown process, e.g. after Stopping target network there is like a 2-minute pause and I don't know what the system is waiting for.

What I am after is a way to diagnose the problem, rather than shooting at the moon.

  • How can I find out what the system is waiting for in those long pauses
  • Or more generally: how can I get more information about what's going on during shutdown, is there a "shutdown log"?
  • How is acpi involved in the shutdown process and how can I find out why it is doing what it is doing?
  • 1
    Trick to read messages only visible for a short while (other than a serial console, which is hard if your laptop doesn't have serial ports—and I'm sure it doesn't): use a cell phone (etc.) camera to take a video of the screen. Then you can pause the video to read messages that are only there for a fraction of a second.
    – derobert
    Oct 13, 2015 at 19:25
  • Have you tried the steps described in the section "Diagnosing Shutdown Problems" in Debugging systemd? Jul 8, 2017 at 11:44
  • Some Intel chipsets (IvyBridge/Haswell or about that time) had a quirky USB3 XHCI controller: if the XHCI controller was not shut down properly, it would cause the system to restart after power-down. The quirk even was subtly different in various versions of the chipset, so pinning down the required shutdown procedure in each case was quite tricky. See bug #66171 in Linux kernel bugzilla.
    – telcoM
    Apr 13, 2019 at 9:44

1 Answer 1


I had the same issue on two different systems, albeit with Wheezy.

The solutions were different:

Solution 1

Blacklisting the kernel module mei_me (Intel Management Engine) fixed the issue on one machine.

Solution 2

On another machine it was a pm-utils issue, try to write on to /sys/bus/*/devices/*/power/control and shutdown.

Source: https://askubuntu.com/questions/132882/why-do-i-get-a-reboot-instead-of-a-shutdown

  • INTEL_MEI is set to "No" in my kernel config. And I don't have any "control" files in /sys/bus/*/devices/*/power/. I don't think this is it. Oct 13, 2015 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.