Bug 1473635 - systemd considers suspend to fail, despite seeming to work fine
systemd considers suspend to fail, despite seeming to work fine
Status: NEW
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-21 06:50 EDT by Alan Jenkins
Modified: 2017-07-25 15:42 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Jenkins 2017-07-21 06:50:42 EDT
Description of problem:

systemd considers suspend.target as failed, despite an apparently successful suspend.

Version-Release number of selected component (if applicable):
systemd-233-6.fc26.x86_64

How reproducible: always


Steps to Reproduce:
1. systemctl suspend
2. Wake the system by pressing the power button.
3. systemctl status suspend.target

Actual results:

$ 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'.


Expected results:

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


Additional info:

I think this is an oversight in how the systemd sleep units are written.  I can't immediately think of a solution.

I think the problem is that systemd-suspend.service goes inactive after resume, and the BindsTo dependency in suspend.target means this causes the target to transition to a failed state.

But I'm not familiar with the exact purpose of the BindsTo dependency in suspend.target.


$ 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
Comment 1 Alan Jenkins 2017-07-21 07:00:30 EDT
Huh, it looks like some change in systemd behaviour of BindsTo, after a very recent package update.  (Possibly the upgrade to Fedora 26):

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.
...
Comment 2 Alan Jenkins 2017-07-21 07:11:49 EDT
As far as I can tell this issue is eligible for tracking by upstream, so I reported https://github.com/systemd/systemd/issues/6419

Note You need to log in before you can comment on or make changes to this bug.