logind: rework delay inhibition logic

- Don't allow any locks to be taken while we are in the process of
  executing the specific operation, so that apps are not surprised if a
  suspend/shutdown happens while they rely on their inhibitor.

- Get rid of the Resumed signal, it was a bad idea, and redundant due to
  PrepareForSleep(false), see below.

- Always send out PrepareFor{Shutdown,Sleep} signals, instead of only if
  a delay lock is taken.

- Move PrepareForSleep(false) after we come back from the suspend, so
  that apps can use this as "Resumed" notification. This also has the
  benefit that apps know when to take a new lock.

1 files changed, 2 insertions, 2 deletions

diff --git a/src/login/logind.c b/src/login/logind.c
index ed0b7489b9..be793e2a93 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -1628,11 +1628,11 @@ int manager_run(Manager *m) {
 
                 manager_gc(m, true);
 
-                if (m->delayed_unit) {
+                if (m->action_what != 0) {
                         usec_t x, y;
 
                         x = now(CLOCK_MONOTONIC);
-                        y = m->delayed_timestamp + m->inhibit_delay_max;
+                        y = m->action_timestamp + m->inhibit_delay_max;
 
                         msec = x >= y ? 0 : (int) ((y - x) / USEC_PER_MSEC);
                 }