I have the problem that my Ubuntu wakes up immediately after suspend, not every time, but when I connect my USB 3.0 mouse.

When I start Ubuntu, it doesn't detect my mouse, so I must plug/unplug it few times, maybe suspend Ubuntu and wake it up. But when mouse is connected and works, then suspend doesn't work.

I tried editing the wakeup file and disabling some S3 lines, but after that, when I suspended Ubuntu, it turned off the screen, but the PC was still running, so it seems that isn't the right way to handle it.

How can I fix this properly?


I was having a similar issue to this one. Apparently, there's a known bug where the bluetooth service is causing Ubuntu to wake up immediately upon suspending https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774994

This was the first link I found when I was googling an answer, which is why I'm posting this solution here.

The solution is basically to have a script ran before and after suspending to start and stop the bluetooth service.

# Makes sure bluetooth service is not running while suspended.

if [ "${1}" == "pre" ]; then
    service bluetooth stop
elif [ "${1}" == "post" ]; then
    service bluetooth start

Save this script as bluetooth-suspend under /lib/systemd/system-sleep and make sure the script can be executed with chmod +x bluetooth-suspend.

That seemed to fix the issue for me.

  • My keyboard is Bluetooth, this solved my wakeup issue.
    – No Sssweat
    Apr 11 '19 at 0:43
  • I started having this problem about a week ago and this answer solved it for me, thanks.
    – MLu
    Sep 2 '19 at 23:17
  • I run Ubuntu 18.04 on an HP ProBook 440 G6, and I use a Logitech BT mouse. This fixed it for me as well. Thanks!
    – noname
    Sep 4 '19 at 17:29

This problem happens on my Ubuntu system as well. When it does, log in again, open a terminal, and run

$ ps aux | grep suspend

If you have the same problem I do, you will see a failed/hanging suspend process. That's what causes the system to start right again, because the suspend isn't finishing itself.

If in the same terminal you try this

$ sudo /sbin/shutdown -h now

you will get a refusal from the system, with a message saying something like that's a destructive transaction, that's the system d's way of saying that as long as that suspend process is hung, you aren't shutting down.

The only fix I know of is to kill the suspend process

$ kill -9 nnnnnn

where nnnnnn is the number of the hanging suspend process you see in the ps aux output.

I tried to track discussion of this in forums on the kernel and drivers, but it is pretty tough going. Some people claim it is being solved by kernel updates, say into the latest 4.6 and 4.8 editions, but I don't see any benefit. My problem, I'm pretty sure, links back to commercial Nvidia drivers that don't always get out of the way.

  • Problem happened today after activating nVidia 384.130 (previously under Intel iGPU only). However there is no hanging suspend process to kill. I did notice in journalctl ACPI is finishing resume just as systemd is starting the suspend process. Still +1 for good answer. Aug 6 '18 at 23:55

It happened to my computer when I used Microsoft Mouse. Before I had used Logitech mouse, then it worked just fine. So I switched back to Logitech one, now it works normally again. I put computer on suspend, it stays.

  • 2
    This isn't a guaranteed answer. A) You don't know if OP problem is with a Microsoft Mouse. B) You don't know if OP has a Logitech mouse to plug in instead. C) It could very well be the OP already has a Logitech mouse and the suspend problem is still happening. Mar 31 '18 at 0:14
  • I found that if I unplug my iHaper C002 USB-C hub before suspending, the computer will stay suspended. You are on the right track observing that USB is causing this. May 23 '19 at 0:49

Had this issue and I struggled to to find the source for a few days. My solution was to first search the log journalctl -b | grep suspend

I found the following:

PM: Device 0000:05:00.0 failed to suspend async: error 1

This line provided the device address that created this issue Than I used lspci to identify the device

05:00.0 ASmedia usb 3.1

Using lspci shows the actual names of devices by address and in my case I remember seeing this on my ASRock Bios so I rebooted and disabled support for ASmedia usb 3.1 and my Desktop suspended successfully.

My case is unique to me but might help others identify the issue.


I had the same problem on linux mint. Tried to mess with configuration file /proc/acpi/wakeup, but that didn't work for me for me. Basically you disable device from waking up the PC completly, which is not what you usually want. You want to be able to use device such as keyboard or mouse to wake up Pc on your command not on its own. finally, the issue solved itself after I switch the usb port i use for keyboard dongle. after that it worked fine, so it might help you too


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.