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
