[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David De La Harpe Golden
Subject: Re: Functions in kill-emacs-hook aren't run if emacs gets killed with SIGTERM
Date: Fri, 23 Jan 2009 19:56:06 +0000
User-agent: Mozilla-Thunderbird (X11/20090103)

Eli Zaretskii wrote:
From: Tassilo Horn <address@hidden>
Cc: Stefan Monnier <address@hidden>,  address@hidden
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

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]