expanding the inhibit spec

[Lennart Poettering]

On Wed, 08.01.14 09:44, Ryan Lortie (desrt at desrt.ca) wrote:

> 
> hi,
> 
> On Wed, Jan 8, 2014, at 4:21, Lennart Poettering wrote:
> > How's that supposed to work? If the shutdown was blocked, its is
> > entirely denied, so who will then reschedule the shutdown later? The
> > word processor which wanted to show this dialog?
> > 
> > Note that our upstream wiki page about shutdown/suspend delay inhibition
> > actually explicitly explains that the delay locks should only be taken
> > when the files they edit "are dirty", and that they should be released
> > as soon as everything is synced to disk. 
> 
> We talked about this once before, last year.  In my opinion, this case
> should be handled by the applications all getting SIGTERM at logout time
> (assuming that there are no proper full "blocks").  If they have things
> that they want to take care of before being killed, they will install a
> SIGTERM handler.  If not, they will die immediately.  After a while
> (5s...), if processes are still around, SIGKILL.

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...

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.

Lennart

-- 
Lennart Poettering, Red Hat