Mechanism to know when all services are finished preparing for resume

Hi systemd-devel,

When using the systemd-logind design for suspend, systemd services can receive the PrepareForSleep DBus signal from systemd-logind with the Boolean argument false to know when the system is exiting from suspend - https://systemd.io/INHIBITOR_LOCKS/

We want to be able to measure the time between triggering a suspend exit (AKA resume), and the moment that the system can be considered “resumed”.

• The definition of resumed would likely be that all systemd services registered with the PrepareForSleep DBus signal have completed their callbacks and re-acquired sleep delay inhibitor locks.

Normally for measuring boot times after power-on, it is very easy to use timestamps of activation of Type=notify services and systemd targets, but when resuming from a low power state with systemd, I’m not sure what the easiest / best practices are. If I understand correctly, as part of systemd-logind’s suspend design, suspend.target is reached before systemd-logind broadcasts PrepareForSleep “false” signal, so suspend.target’s activation timestamp does not represent the time that systemd services have had the opportunity to re-acquire sleep delay inhibitor locks.

Some ideas…

Is there some way for a systemd target to be dependent on services reaching some custom state like “resumed”?

Another idea could be to have another systemd service, let’s say it is called “suspend-listener.service”, started at boot time to which systemd services that acquire sleep delay inhibitor locks would register with. Then after these registered services re-acquire sleep delay inhibitor locks, they notify suspend-listener that they are successfully resumed. Only once suspend-listener is notified that all registered services have resumed successfully, the system is considered “resumed”.

Or suspend-listener could have a predefined list of services that need to acquire inhibitor locks, and it itself can register with PrepareForSleep. When it receives PrepareForSleep “false”, suspend-listener could busy-poll ListInhibitors DBus method until all predefined services have successfully re-acquired sleep delay inhibitor locks.

Thank you,

Eric