Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sourcejedi opened this Issue Jul 21, 2017 · 13 comments

Comments

8 participants
@sourcejedi
Copy link
Contributor

sourcejedi commented Jul 21, 2017

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

This comment has been minimized.

Copy link

mhoeher commented Jul 25, 2017

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

This comment has been minimized.

Copy link
Contributor Author

sourcejedi commented Jul 26, 2017

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 comment has been minimized.

Copy link

sheinz commented Jul 28, 2017

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

@poettering poettering added this to the v235 milestone Jul 31, 2017

@somini

This comment has been minimized.

Copy link

somini commented Aug 1, 2017

@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 comment has been minimized.

Copy link

rafasc commented Aug 4, 2017

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

This comment has been minimized.

Copy link

mhoeher commented Aug 5, 2017

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

This comment has been minimized.

Copy link

somini commented Aug 7, 2017

@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

This comment has been minimized.

Copy link

mhoeher commented Aug 7, 2017

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

This comment has been minimized.

Copy link

SeeLook commented Aug 15, 2017

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?

@teh teh referenced this issue Aug 16, 2017

Merged

Gnome 3.24 #28053

@sandys

This comment has been minimized.

Copy link

sandys commented Aug 19, 2017

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

This comment has been minimized.

Copy link

somini commented Aug 19, 2017

@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

This comment has been minimized.

Copy link

sandys commented Aug 19, 2017

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

@somini

This comment has been minimized.

Copy link

somini commented Aug 19, 2017

That seems a different (and weird) bug. Try opening a different issue here, perhaps.

With that "Delay lock" line with timeout after 5 seconds, it seems some other program is subscribing to the suspend event and shutting down perhaps. Try systemd-inhibit --list.

sourcejedi added a commit to sourcejedi/systemd that referenced this issue Aug 27, 2017

units: starting suspend.target should not fail when suspend is succes…
…sful

and the same for hibernate.target and hybrid-sleep.target.

Tested with both sucessful and unsuccessful suspends.  The result of the
start job was correct in both cases.  Closes systemd#6419 (a regression in v233
and v234).

> 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/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.

This commit switches suspend.target etc. to the approach used by
sleep.target.

poettering added a commit that referenced this issue Aug 30, 2017

units: starting suspend.target should not fail when suspend is succes…
…sful (#6678)

and the same for hibernate.target and hybrid-sleep.target.

Tested with both sucessful and unsuccessful suspends.  The result of the
start job was correct in both cases.  Closes #6419 (a regression in v233
and v234).

> 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/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.

This commit switches suspend.target etc. to the approach used by
sleep.target.

andir added a commit to andir/systemd that referenced this issue Sep 7, 2017

units: starting suspend.target should not fail when suspend is succes…
…sful (systemd#6678)

and the same for hibernate.target and hybrid-sleep.target.

Tested with both sucessful and unsuccessful suspends.  The result of the
start job was correct in both cases.  Closes systemd#6419 (a regression in v233
and v234).

> 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/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.

This commit switches suspend.target etc. to the approach used by
sleep.target.

andir added a commit to andir/systemd that referenced this issue Sep 22, 2017

units: starting suspend.target should not fail when suspend is succes…
…sful (systemd#6678)

and the same for hibernate.target and hybrid-sleep.target.

Tested with both sucessful and unsuccessful suspends.  The result of the
start job was correct in both cases.  Closes systemd#6419 (a regression in v233
and v234).

> 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/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.

This commit switches suspend.target etc. to the approach used by
sleep.target.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.