Regression: systemd considers suspend to fail, despite seeming to work fine

[sourcejedi]

Submission type

• Bug report

systemd version the issue has been seen with

systemd-233-6.fc26.x86_64

Used distribution

Fedora Linux 26

In case of bug report: Expected behaviour you didn't see

Job suspend.target/start does not fail, during a successful suspend/resume cycle.

In case of bug report: Unexpected behaviour you saw

This started happening recently, after what I assume is a systemd package update.

$ journalctl -u suspend.target
...
Jul 13 19:07:48 alan-laptop systemd[1]: Reached target Suspend.
Jul 13 19:07:48 alan-laptop systemd[1]: suspend.target: Unit is bound to inactive unit systemd-suspend.service. Stopping, too.
Jul 13 19:07:48 alan-laptop systemd[1]: Stopped target Suspend.
-- Reboot --
Jul 13 22:28:16 alan-laptop systemd[1]: suspend.target: Bound to unit systemd-suspend.service, but unit isn't active.
Jul 13 22:28:16 alan-laptop systemd[1]: Dependency failed for Suspend.
...

In case of bug report: Steps to reproduce the problem

1. systemctl suspend
2. Wake the system by pressing the power button.
3. systemctl status suspend.target

Additional information

$ systemctl status suspend.target
● suspend.target - Suspend
Loaded: loaded (/usr/lib/systemd/system/suspend.target; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd.special(7)

Jul 21 11:39:56 alan-laptop systemd[1]: suspend.target: Bound to unit systemd-suspend.service, but unit isn't active.
Jul 21 11:39:56 alan-laptop systemd[1]: Dependency failed for Suspend.
Jul 21 11:39:56 alan-laptop systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.

$ systemctl status systemd-suspend.service
● systemd-suspend.service - Suspend
Loaded: loaded (/usr/lib/systemd/system/systemd-suspend.service; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd-suspend.service(8)

Jul 21 11:39:52 alan-laptop systemd[1]: Starting Suspend...
Jul 21 11:39:52 alan-laptop systemd-sleep[7812]: Suspending system...
Jul 21 11:39:56 alan-laptop systemd[1]: Started Suspend.

$ systemctl list-dependencies -a suspend.target
suspend.target
● └─systemd-suspend.service
● ├─system.slice
● │ └─-.slice
● └─sleep.target

[mhoeher]

I can confirm this issue - am getting the very same logs (also running systemd 233 on Fedora 26).

While suspend itself nevertheless seems to work, this issue seems to break execution of dependent units and scripts/programs in /usr/lib/systemd/system-sleep/. For example, I set up a unit which wakes the system up from suspend after 2 hours and automatically goes to hibernate to save battery and increase security due to full disk encryption which kicks in with the hibernate state.

When instead of a unit file I tried to realize this functionality by putting a script into /usr/lib/systemd/system-sleep/, the script also does not seem to be executed.

For my private laptop I can well live without this feature for the moment, however, this is a bummer for my work laptop :(

[sourcejedi]

Hmm. suspend is unsual for a target, because it has to stop itself once it's started. Otherwise you couldn't start it again, so you could only suspend once! Currently that's implemented using BindsTo=systemd-sleep.service. Meaning it pulls in systemd-sleep.service to do the actual suspend, and then de-activates afterwards. But the behaviour of BindsTo was changed recently (not without some issues during development) - maybe this bug is caused by poettering@631b676 which I think was added in release v233.

The interesting thing is that sleep.target (see man systemd.special) has the same need, but it implements it differently. It simply has StopWhenUnneeded=yes. Maybe we could use that on suspend.target instead of the BindsTo.

[sheinz]

This issue influences Delayed hibernation in Arch linux.
Fail in suspend.target causes suspend-to-hibernate.service never to stop.

[somini]

@sheinz I'm using the same unit as that wiki page and have the same problem as you. I fixed it by ignoring the last systemd fix:

With recent systemd release, you must also edit the suspend.target file by adding a Requires=suspend-to-hibernate.service line to the [Unit] section (source)

Removing the dependency on suspend-to-hibernate to suspend.target will restore past behaviour, but the suspend.target still fails.

---

EDIT: False alarm, it is impossible to hibernate from the suspend-to-hibernate.service, because when that unit is stopped, suspend.target is still active, even though that hook explicitly includes

Before=suspend.target

[rafasc]

This is probably the wrong place to comment, but since the main thing this is affecting is the suspend-to-hibernate.service:

Looks like the behaviour can be restored if you remove the Before=suspend.target from suspend-to-hibernate.service and Requires=suspend-to-hibernate.service from suspend.target

[mhoeher]

Thanks @rafasc! Modifying the suspend.target and suspend-to-hibernate.service as you suggested indeed seems to let the suspend-to-hibernate script work as intended. :-) The suspend target still yields the weird "dependency failed" error logs, however, with your changes the two services seem to get decoupled so the suspend-to-hibernate service is executed properly now.

So in some regard, the "new" behavior of systemd even is good, because now there's no need to modify the suspend.target to get delayed hibernation to work. Of course, it would be better if backwards compatibility would be ensured, so existing setups don't just break.

[somini]

@rafasc At first your fixed worked, but then I noticed the suspend-to-hibernate service only worked sometimes. After digging through journal logs, I noticed the system suspended before the suspend-to-hibernate service had a chance to finish. The fix is making sure it starts before, so Before= is the line to use.
We need to depend on the sleep.target instead of the suspend.target to get executed when the loginctl "lock" for the suspend operation has already been released.
With this fix my system can suspend-to-hibernate deterministically, but I would like confirmation from @rafasc and @mhoeher.

TLDR: The fix is adding Before=sleep.target to the service. I updated the Arch Wiki

[mhoeher]

Hi @somini,

I changed my service file as you suggested and retried several times to suspend my machine. The delayed hibernation worked without issues, so I guess your changes are correct.

[SeeLook]

Hi,
I'm struggling with that issue under Arch, but I don't using suspend-to-hibernate service.
Behavior is weird, laptop suspends itself once or resumes itself when suspended without any "outside" reason.

I got that:

$journalctl -u suspend.target
: suspend.target: Bound to unit systemd-suspend.service, but unit isn't active.
: Dependency failed for Suspend.
: suspend.target: Job suspend.target/start failed with result 'dependency'.

Is there a way to fix it myself?

[sandys]

hi guys,
on fedora 26, my suspend causes my laptop (XPS 13) to shutdown. I just need plain vanilla suspend (on lid close ) to work again.
is this the same bug that's impacting me ?
these are my logs

Apr 17 20:50:53 menzoberranzan systemd[1]: Reached target Suspend.
Apr 17 20:50:53 menzoberranzan systemd[1]: suspend.target: Unit is bound to inactive unit systemd-suspend.service. Stopping, too.
Apr 17 20:50:53 menzoberranzan systemd[1]: Stopped target Suspend.
Apr 17 22:17:51 menzoberranzan systemd[1]: Reached target Suspend.

[somini]

@sandys this bug is unrelated.

To solve your problem try looking into logind configuration, but note that GNOME messes with that, it has its own configuration.
https://www.freedesktop.org/software/systemd/man/logind.conf.html

[sandys]

@somini thanks for replying.
This problem (that suspend actually shuts down my laptop) also occurs if I run "sudo systemctl suspend". Is there a way to find out what is happening ... debug log or something that I can generate ?

if it helps, this is my logind log.

-- Reboot --
Aug 19 18:40:26 menzoberranzan systemd[1]: Starting Login Service...
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: New seat seat0.
Aug 19 18:40:26 menzoberranzan systemd[1]: Started Login Service.
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event3 (Power Button)
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event5 (Video Bus)
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event1 (Power Button)
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event0 (Lid Switch)
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event2 (Sleep Button)
Aug 19 18:40:26 menzoberranzan systemd-logind[960]: Watching system buttons on /dev/input/event7 (Dell WMI hotkeys)
Aug 19 18:40:27 menzoberranzan systemd-logind[960]: New session c1 of user gdm.
Aug 19 18:40:34 menzoberranzan systemd-logind[960]: New session 2 of user user.
Aug 19 18:44:48 menzoberranzan systemd-logind[960]: Delay lock is active (UID 0/root, PID 1346/upowerd) but inhibitor timeout is reached.
-- Reboot --
Aug 19 18:45:11 menzoberranzan systemd[1]: Starting Login Service...
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: New seat seat0.
Aug 19 18:45:12 menzoberranzan systemd[1]: Started Login Service.
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event3 (Power Button)
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event5 (Video Bus)
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event1 (Power Button)
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event0 (Lid Switch)
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event2 (Sleep Button)
Aug 19 18:45:12 menzoberranzan systemd-logind[973]: Watching system buttons on /dev/input/event7 (Dell WMI hotkeys)
Aug 19 18:45:13 menzoberranzan systemd-logind[973]: New session c1 of user gdm.
Aug 19 18:45:20 menzoberranzan systemd-logind[973]: New session 2 of user user.
Aug 19 19:06:37 menzoberranzan systemd-logind[973]: New session 3 of user root.
Aug 19 19:07:29 menzoberranzan systemd-logind[973]: Removed session 3.
Aug 19 19:33:26 menzoberranzan systemd-logind[973]: Lid closed.
Aug 19 19:33:26 menzoberranzan systemd-logind[973]: Suspending...
Aug 19 19:33:31 menzoberranzan systemd-logind[973]: Delay lock is active (UID 0/root, PID 1344/upowerd) but inhibitor timeout is reached.
-- Reboot --