expanding the inhibit spec

[Ryan Lortie]

hi,

On Thu, Jan 9, 2014, at 7:47, Lennart Poettering wrote:
> Well, I certainly think apps should handle SIGTERM properly, and what
> you describe above is actually what systemd does for all processes it
> runs. However, it's something that only works if the operation to delay
> is actually one that necessarily ends up in process termination, and
> which never needs to be reversed. This is not true for
> hibernation/suspending/hybrid for example...

This is specifically why I believe that suspend(/hibernate) should have
a separate delay mechanism still made available.

> The delay locks how logind implements them right now have the benefit
> that they are globally staged: we ask programs to prepare for shutdown
> without actually telling them to shutdown. Only when everything went
> according to plan and we still desire to execute the operation then we
> will go to the next step and actually shut down things... Your SIGTER
> approach otoh is destructive immediately: it's a much stricter request
> to apps, they not only have to prepare for the operation they also hve
> to do it.

>From a UI standpoint this "we must do it now" approach it exactly what I
want.  I don't like the possibility that an application can go from
"tell me when you're shutting down so I can tend to some last minute
things" to "oh wait!  stop!  abort!".  Once the first app has been told
"prepare yourself", it should not be possible for another app to
interrupt the process.

That's why I prefer two completely separate mechanisms: block to stop
the process from occurring in the first place, and (if no blocks are
there) a round of signals, after which there is absolutely nothing that
apps can do to prevent the shutdown from proceeding.

Cheers