Comment 99 for bug 1252121

Thanks LoÏc. For the record, it's expected that systemd-shim times out after some seconds of inactivity. So the shim log looks fine, and indeed the PrepareForSleep False is missing, as with other people. At this point this requires an in-depth debugging of systemd-logind, to see why it sometimes fails to send out the PrepareForSleep false after resuming. Supposedly systemd-shim doesn't simulate the suspend.target & friends convincingly enough and we are missing something important there.

I'm not familiar with the inner workings of logind either, so I'm afraid I cannot give much helpful advice what could be wrong there. Just some hints if anyone wants to take a stab:

 - It's perfectly acceptable to kill a running logind and start it in the foreground, even from a built tree; it will pick up the state from /run/ and /sys/fs/cgroups/. That makes it easier for "add debug info"/compile/run/suspend cycles.

 - It's probably also helpful to edit /usr/sbin/pm-suspend to "exit 0" at the start, so that the machine doesn't actually suspend; of course before doing this you should ensure that this actually still reproduces the bug; if not, and it turns out to be some timing issue, then you could also put a "sleep N" in front of it, and check for which values of N it starts working/failing.