On Wed, 08.01.14 09:44, Ryan Lortie (de...@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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg