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
Closed

Comments

@sourcejedi
Copy link
Contributor

@sourcejedi 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
Copy link

@mhoeher 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
Copy link
Contributor Author

@sourcejedi 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
Copy link

@sheinz 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
Copy link

@somini 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
Copy link

@rafasc 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
Copy link

@mhoeher 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
Copy link

@somini 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
Copy link

@mhoeher 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
Copy link

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

@sandys
Copy link

@sandys 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
Copy link

@somini 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
Copy link

@sandys 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
Copy link

@somini 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
…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
…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
…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
…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.
Werkov pushed a commit to Werkov/systemd that referenced this issue Jun 3, 2020
…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.

(cherry picked from commit 64a36ae)

[fbui: fixes bsc#1172072]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants