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

[David De La Harpe Golden <david@harpegolden.net>]

Eli Zaretskii wrote:
>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Fri, 23 Jan 2009 16:58:03 +0100
>>
>> Init or start-stop-daemon do that.
>>
>>> Why can't they use SIGUSRn?
>> Because SIGUSRn has different meanings across applications, so the only
>> reliable way to terminate a program is "kill <pid>" which send a
>> SIGTERM.
> 
> You can run your own script when the machine is shut down, can't you?
> Then have that script deliver a SIGUSRn signal to Emacs and wait a few
> moments for it to shut down peacefully.
> 


Uh, but SIGTERM IS "please shutdown". Sorry, but _conventionally_ 
automated systems* will issue a SIGTERM to allow graceful shutdown, then 
a SIGKILL a few seconds later if the process hasn't promptly terminated 
like a good little process should.

This is mere convention on unix and gnu, but is a very long standing one 
at this stage? Certainly USRn shouldn't be used where TERM would do and 
is conventional...

SIGKILL, of course, is not a normal signal, it's a signal to the kernel 
to kill and eat the process whether the process likes it or not. But 
SIGTERM is a normal signal and it's IMO fine for emacs to do lots of
cleanup actions before exit upon its receipt.  So long as the emergency 
  save happens ASAP, I'd consider dropping back to the main
loop having queued an event that runs kill emacs hooks then exits upon 
SIGTERM (avoiding issues with running lisp code directly from a signal 
handler)- if there's a bug in one of the hooks, well, that just means 
emacs will then be kill -9'd, but that's life.

SIGUSR1 should maybe close and reopen the emacsclient socket
(see init, where USR1 closes and reopens the socket).

* initscripts/daemon managers, batch systems like PBS...

e.g.

"When init is requested to change the runlevel, it sends the warning 
signal SIGTERM to all processes that are undefined in the new runlevel. 
It then waits 5 seconds before forcibly terminating these processes via 
the SIGKILL signal."  - init

"All processes are first notified that the system is going down by the 
signal SIGTERM. This gives programs like vi(1) the time to save the file 
being edited, mail and news processing programs a chance to exit 
cleanly, etc"  - shutdown

  "A batch job being deleted by a server will be sent a SIGTERM signal 
following by a SIGKILL signal. The time delay between the two signals is 
an attribute of the execution queue... " - qdel (from PBS.)