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, 1 insertions, 1 deletions

diff --git a/src/login/logind-action.c b/src/login/logind-action.c
index a796ebe9e..1e529e1c9 100644
--- a/src/login/logind-action.c
+++ b/src/login/logind-action.c
@@ -60,7 +60,7 @@ int manager_handle_action(
 
         assert(m);
 
-        if (m->action_job || m->delayed_unit) {
+        if (m->action_what) {
                 log_debug("Action already in progress, ignoring.");
                 return -EALREADY;
         }