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

[Tassilo Horn]

Eli Zaretskii <address@hidden> writes:

>> From: Tassilo Horn <address@hidden>
>> Cc: Stefan Monnier <address@hidden>,  address@hidden
>> Date: Mon, 02 Feb 2009 21:52:29 +0100
>> 
>> > Anyway, Dan suggested a better way long ago, so it's IMO pointless to
>> > continue this argument.
>> 
>> Do you have a message-id / url at hand?
>
> No, but it should be in this thread, IIRC.

Ok, I think you mean <address@hidden>
where Dan suggests to shutdown emacs --daemon with:

  emacsclient --eval "(save-buffers-kill-emacs)"

I agree that this is a good way to shutdown emacs, but it won't work in
cases the server doesn't accept a connection anymore.  And it forces
users to add snippets like this to some rc file that is executed on
system shutdown, one snippet for each running daemon process.

I'm not sure how that could be done.  Iterating over the socket files in
/tmp/emacsUID/ may work.  But maybe someone uses TCP connections on the
local system and you'd have to distinguish between local and remote
processes where the latter must not be killed.

I think this can be quite complex whereas a SIGTERM is sent to any local
process by init, anyway.

I'm not strictly against the "SIGTERM should not cause kill-emacs-hook
to be run" argument, but at least the use-case of users forgetting to
kill all emacs processes on system shutdown should be considered with
new (very nice!) features like --daemon and multi-tty.  I currently see
two solutions:

  1) Run kill-emacs-hook after saving all buffers when a SIGTERM was
     received, or

  2) provide a shell script which figures out all emacs daemon processes
     and shuts them down like Dan suggested.

Point 2 has the disadvantage of failing with broken daemons, but
nevertheless that's an error case, so maybe it would be a good idea not
to run kill-emacs-hook here anyway.

Bye,
Tassilo