From 314b4b0a68d9ab35de981923a088fc8c8820caa5 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Fri, 25 Jan 2013 06:30:23 +0100 Subject: 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. --- src/login/logind-action.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/login/logind-action.c') diff --git a/src/login/logind-action.c b/src/login/logind-action.c index a796ebe9ec..1e529e1c98 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; } -- cgit v1.2.3-54-g00ecf