Re: Functions in kill-emacs-hook aren't run if emacs gets killed with SIGTERM

[Tassilo Horn <tassilo@member.fsf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > No.  Fatal signals, such as SIGTERM, are caught by a signal
>> > handler, which runs emacs.c:shut_down_emacs.  `kill-emacs' in a
>> > nutshell runs `kill-emacs-hook' and then also calls
>> > shut_down_emacs.
>> 
>> It would probably make sense to run kill-emacs-hook when we receive
>> SIGTERM, although it does imply a significant change (basically
>> handling SIGTERM similarly to SIGUSRn).
>
> SIGUSRn are different in that they are ``soft'', and are not generally
> expected to interrupt code in dangerous state.  The fact that SIGTERM
> in this case is a programmed means to stop Emacs does not mean it's
> the only use case where SIGTERM is delivered to Emacs.  We shouldn't
> IMO change code based just on this single use case.

Is SIGTERM really such a fatal signal as you say?  I always believed
SIGTERM meant "shutdown, but do it cleanly" whereas SIGKILL meant "Die!
Die! Die! NOW!".  That's the reason tools like init first send SIGTERM
to all apps when shutting down to give them a chance to do some
organizational stuff before exiting, and after some seconds they fire a
SIGKILL to apps which didn't obey.

Maybe it would be sensible to do the buffer saving first on SIGTERM, so
that we're in a hopefully save state, then run `kill-emacs-hook' and
finally shut down.  That would minimize the risk of a function in
`kill-emacs-hook' to cause any harm.

Bye,
Tassilo