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

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

[Tassilo Horn]

Hi,

I use emacs --daemon as system service and it's started and stopped by
the start-stop-daemon utility.  Now I found out that all the functions
in `kill-emacs-hook' aren't run when start-stop-daemon stops the emacs
process.  I'm not sure how it stops it, but I think it's by sending a
SIGTERM to the process, waiting some seconds and then firing an SIGKILL
if the process didn't finish.

How does emacs handle SIGTERM?  Doesn't it simply run `kill-emacs'?  At
least that's what I would expect.

A related question: What does emacs --daemon do when it receives a
SIGTERM and there are unsaved buffers?

Bye,
Tassilo

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

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Wed, 21 Jan 2009 09:06:58 +0100
> 
> How does emacs handle SIGTERM?  Doesn't it simply run `kill-emacs'?

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.

> At least that's what I would expect.

I don't think it's a good idea to run Lisp code from within a fatal
signal handler.  shut_down_emacs saves all unsaved buffers and cleans
up the terminal, but doesn't do anything else, because Emacs's
internal data structures can be very unstable at this point.

> A related question: What does emacs --daemon do when it receives a
> SIGTERM and there are unsaved buffers?

Sorry, I don't know.  Someone else will have to answer this.

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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> How does emacs handle SIGTERM?  Doesn't it simply run `kill-emacs'?
>
> 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.

Hm, at least if emacs runs as a daemon, I'd say that a simple "killall
emacs" (most probably by some script) is the standard way of stopping
it.  Nobody wants to open a new frame just to shutdown emacs.

>> At least that's what I would expect.
>
> I don't think it's a good idea to run Lisp code from within a fatal
> signal handler.  shut_down_emacs saves all unsaved buffers and cleans
> up the terminal, but doesn't do anything else, because Emacs's
> internal data structures can be very unstable at this point.

So what's the right way to shutdown emacs running as a daemon
noninteractively?

  emacsclient --eval '(kill-emacs)'

queries for user input and waits till one connects and answers.

Bye,
Tassilo

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

[Chong Yidong]

Tassilo Horn <tassilo@member.fsf.org> writes:

> So what's the right way to shutdown emacs running as a daemon
> noninteractively?
>
>   emacsclient --eval '(kill-emacs)'
>
> queries for user input and waits till one connects and answers.

I've checked in a fix for this.

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

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

>> So what's the right way to shutdown emacs running as a daemon
>> noninteractively?
>>
>>   emacsclient --eval '(kill-emacs)'
>>
>> queries for user input and waits till one connects and answers.
>
> I've checked in a fix for this.

Thanks, it works.  (But still I'd prefer kill <pid>.)

Bye,
Tassilo

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

[Stefan Monnier]

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

>> A related question: What does emacs --daemon do when it receives a
>> SIGTERM and there are unsaved buffers?
> Sorry, I don't know.  Someone else will have to answer this.

I think it just does autosaves and then exits.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Tassilo Horn <tassilo@member.fsf.org>,  emacs-devel@gnu.org
> Date: Wed, 21 Jan 2009 15:36:12 -0500
> 
> > 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.

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

[Tassilo Horn]

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

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

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Thu, 22 Jan 2009 10:00:43 +0100
> 
> 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!".

No, the reason is that SIGKILL cannot be caught or ignored, whereas
SIGTERM can.  Which has the practical effect that you mention, but
it's IMO important to understand the underlying reason.

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

[mail]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tassilo Horn <tassilo@member.fsf.org>
>> 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!".
>
> No, the reason is that SIGKILL cannot be caught or ignored, whereas
> SIGTERM can.  Which has the practical effect that you mention, but
> it's IMO important to understand the underlying reason.

I don't understand what you're trying to say. The reason that SIGKILL
cannot be ignored is that it means "Die! Die! Die! NOW!", and the reason
that SIGTERM can is that it means "shutdown, but do it cleanly". Ie, the
reasons and practical effects are exactly opposite of what you seem to
be saying: could you explain in more detail?

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

[Eli Zaretskii]

> From: mail@justinbogner.com
> Date: Thu, 22 Jan 2009 19:15:30 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Tassilo Horn <tassilo@member.fsf.org>
> >> 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!".
> >
> > No, the reason is that SIGKILL cannot be caught or ignored, whereas
> > SIGTERM can.  Which has the practical effect that you mention, but
> > it's IMO important to understand the underlying reason.
> 
> I don't understand what you're trying to say. The reason that SIGKILL
> cannot be ignored is that it means "Die! Die! Die! NOW!", and the reason
> that SIGTERM can is that it means "shutdown, but do it cleanly". Ie, the
> reasons and practical effects are exactly opposite of what you seem to
> be saying: could you explain in more detail?

I don't see how can I explain this in more detail, because you seem to
mix a _meaning_ (i.e. semantics, which is a human thing) with the
software implementation chosen to achieve it, which is the reason for
the immediate exit.

IOW, a meaning humans ascribe to some mechanism cannot be the reason
for what happens when that mechanism is activated.

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> SIGUSRn are different in that they are ``soft'', and are not generally
> expected to interrupt code in dangerous state.

SIGUSR[12] are not softer than SIGTERM in any way, all terminate the
process by default, and can interrupt the process in any state.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> 	tassilo@member.fsf.org, emacs-devel@gnu.org
> Date: Thu, 22 Jan 2009 11:08:32 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > SIGUSRn are different in that they are ``soft'', and are not generally
> > expected to interrupt code in dangerous state.
> 
> SIGUSR[12] are not softer than SIGTERM in any way, all terminate the
> process by default, and can interrupt the process in any state.

I meant the accepted practices of their use, not the underlying signal
delivery mechanism.

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

[Richard M Stallman]

The main difference between SIGUSRx and SIGTERM is that SIGTERM is the
normal way to stop a process, while SIGUSRx are meant for
communication to it.

So it seems to me that Emacs should pass SIGUSRx to Lisp code and
otherwise ignore it.  I believe that's what it did in the past.  At
some point it pushed an event which could run a command later.

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

[Stefan Monnier]

> SIGUSRn are different in that they are ``soft'', and are not generally
> expected to interrupt code in dangerous state.

I don't know what you mean by "interrupt code in dangerous state".
AFAIK, the only difference between SIGTERM and SIGUSRn is that SIGTERM
has a clear intention "please exit now", whereas the other ones's
intention is user-specified.

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

Definitely, but in all cases I can think of, running kill-emacs-hook is
a good idea.  This assumes that the functions placed on kill-emacs-hook
follow the recommendation of the docstring:

   Since `kill-emacs' may be invoked when the terminal is disconnected
   (or in other similar situations), functions placed on this hook
   should not expect to be able to interact with the user.

Maybe another option is to first perform the autosaves (like
shut_down_emacs does), and then run a hook.  This way, no matter what
the hook does, no data is lost.


        Stefan

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

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> Cc: <tassilo@member.fsf.org>,
> 	<emacs-devel@gnu.org>
> Date: Thu, 22 Jan 2009 09:41:03 -0500
> 
> > SIGUSRn are different in that they are ``soft'', and are not generally
> > expected to interrupt code in dangerous state.
> 
> I don't know what you mean by "interrupt code in dangerous state".
> AFAIK, the only difference between SIGTERM and SIGUSRn is that SIGTERM
> has a clear intention "please exit now", whereas the other ones's
> intention is user-specified.

Right, and that's what I meant: SIGTERM usually causes an exit, while
SIGUSR can set a flag and do its thing later.

> > 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.
> 
> Definitely, but in all cases I can think of, running kill-emacs-hook is
> a good idea.  This assumes that the functions placed on kill-emacs-hook
> follow the recommendation of the docstring:
> 
>    Since `kill-emacs' may be invoked when the terminal is disconnected
>    (or in other similar situations), functions placed on this hook
>    should not expect to be able to interact with the user.

I'm more worried by the possibility that they run Lisp code when Emacs
is in unstable state.

> Maybe another option is to first perform the autosaves (like
> shut_down_emacs does), and then run a hook.

I'm not sure this is enough.  We may need to defer exiting until it is
safe to call Lisp code.

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

[Stefan Monnier]

>> I don't know what you mean by "interrupt code in dangerous state".
>> AFAIK, the only difference between SIGTERM and SIGUSRn is that SIGTERM
>> has a clear intention "please exit now", whereas the other ones's
>> intention is user-specified.
> Right, and that's what I meant: SIGTERM usually causes an exit, while
> SIGUSR can set a flag and do its thing later.

It's common for SIGTERM to delay the exit a little bit.
It usually affords to do some cleanup (e.g. we perform autosaves).

>> > 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.
>> 
>> Definitely, but in all cases I can think of, running kill-emacs-hook is
>> a good idea.  This assumes that the functions placed on kill-emacs-hook
>> follow the recommendation of the docstring:
>> 
>> Since `kill-emacs' may be invoked when the terminal is disconnected
>> (or in other similar situations), functions placed on this hook
>> should not expect to be able to interact with the user.

> I'm more worried by the possibility that they run Lisp code when Emacs
> is in unstable state.

The only sane way to implement it is via an event, just like SIGUSRn, so
I don't see why there would be such a risk.  The risk would rather be
the opposite: that by delaying execution to a safe time, we may delay it
indefinitely.

>> Maybe another option is to first perform the autosaves (like
>> shut_down_emacs does), and then run a hook.
> I'm not sure this is enough.  We may need to defer exiting until it is
> safe to call Lisp code.

I'm sure I understand what you mean by "enough", because I'm not sure
what you think is necessary.  To me what is necessary is:
1 - don't lose data.
2 - exit reasonably promptly.
So doing the autosaves before running the hook should make sure
1 is preserved.  But running the hook may indeed make us lose 2.
Is that what you meant by "not enough"?

To keep number 2, we could schedule a SIGALRM so as to forcefully exit
after a timeout, in case running the hook doesn't happen quickly enough.


        Stefan

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

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> Cc: <tassilo@member.fsf.org>,
> 	<emacs-devel@gnu.org>
> Date: Thu, 22 Jan 2009 16:16:37 -0500
> 
> > I'm more worried by the possibility that they run Lisp code when Emacs
> > is in unstable state.
> 
> The only sane way to implement it is via an event, just like SIGUSRn, so
> I don't see why there would be such a risk.  The risk would rather be
> the opposite: that by delaying execution to a safe time, we may delay it
> indefinitely.

We may also delay it indefinitely if we run Lisp, because that could
infloop, especially if our internal data structures are unstable.

> I'm sure I understand what you mean by "enough", because I'm not sure
> what you think is necessary.  To me what is necessary is:
> 1 - don't lose data.
> 2 - exit reasonably promptly.
> So doing the autosaves before running the hook should make sure
> 1 is preserved.  But running the hook may indeed make us lose 2.
> Is that what you meant by "not enough"?
> 
> To keep number 2, we could schedule a SIGALRM so as to forcefully exit
> after a timeout, in case running the hook doesn't happen quickly enough.

On balance, I would leave things as they are, i.e. don't run
kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
so only the minimum necessary cleanup should be in order.

If SIGTERM is used to programmatically shut down Emacs, I think it's
rather a conceptual bug in whatever uses SIGTERM for that purpose.
Why can't they use SIGUSRn?

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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm sure I understand what you mean by "enough", because I'm not sure
>> what you think is necessary.  To me what is necessary is:
>> 1 - don't lose data.
>> 2 - exit reasonably promptly.
>> So doing the autosaves before running the hook should make sure
>> 1 is preserved.  But running the hook may indeed make us lose 2.
>> Is that what you meant by "not enough"?
>> 
>> To keep number 2, we could schedule a SIGALRM so as to forcefully
>> exit after a timeout, in case running the hook doesn't happen quickly
>> enough.
>
> On balance, I would leave things as they are, i.e. don't run
> kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
> so only the minimum necessary cleanup should be in order.

Well, at least it should be customizable (with Stefan's approach above).
Since I run emacs as daemon I create and delete frames on demand and
usually forget to terminate it manually before shutting down my
computer.  And in `kill-emacs-hook' I run some quite important functions
(save chat logs, recentf and stuff) which aren't executed when init
kills emacs with SIGTERM.

> If SIGTERM is used to programmatically shut down Emacs, I think it's
> rather a conceptual bug in whatever uses SIGTERM for that purpose.

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.

Bye,
Tassilo

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

[Eli Zaretskii]

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

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

[David De La Harpe Golden]

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

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

[Eli Zaretskii]

> Date: Fri, 23 Jan 2009 19:56:06 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> Uh, but SIGTERM IS "please shutdown". Sorry, but _conventionally_ 
> automated systems* will issue a SIGTERM to allow graceful shutdown

And Emacs obeys this.  The argument is not whether Emacs obeys
SIGTERM, the argument is whether user-defined hooks should run when we
are hit with SIGTERM.

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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Uh, but SIGTERM IS "please shutdown". Sorry, but _conventionally_
>> automated systems* will issue a SIGTERM to allow graceful shutdown
>
> And Emacs obeys this.  The argument is not whether Emacs obeys
> SIGTERM, the argument is whether user-defined hooks should run when we
> are hit with SIGTERM.

I don't get what could be so dangerous running a user-defined hook after
all buffers have been saved, as Stefan suggested.  The worst case I can
imagine is that one of the functions accesses a file but is too slow,
and a subsequent SIGKILL causes some data loss.

But with the current way *every* SIGTERM causes data loss for me.

Bye,
Tassilo

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

[Lennart Borgman]

On Sat, Jan 24, 2009 at 12:00 AM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Uh, but SIGTERM IS "please shutdown". Sorry, but _conventionally_
>>> automated systems* will issue a SIGTERM to allow graceful shutdown
>>
>> And Emacs obeys this.  The argument is not whether Emacs obeys
>> SIGTERM, the argument is whether user-defined hooks should run when we
>> are hit with SIGTERM.
>
> I don't get what could be so dangerous running a user-defined hook after
> all buffers have been saved, as Stefan suggested.  The worst case I can
> imagine is that one of the functions accesses a file but is too slow,
> and a subsequent SIGKILL causes some data loss.
>
> But with the current way *every* SIGTERM causes data loss for me.

I did not follow this closely, but maybe this is hitting a problem in GNU/Linux?

I compare with w32 where the shutdown process waits if some program
has problem exiting.

Regarding Stefans suggestion the only useful thing to do is AFAICS to
save some things to a file, so yes, there might be a problem - but
probably not worse than doing nothing.

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

[Tassilo Horn]

Lennart Borgman <lennart.borgman@gmail.com> writes:

Hi Lennart,

>>> And Emacs obeys this.  The argument is not whether Emacs obeys
>>> SIGTERM, the argument is whether user-defined hooks should run when
>>> we are hit with SIGTERM.
>>
>> I don't get what could be so dangerous running a user-defined hook
>> after all buffers have been saved, as Stefan suggested.  The worst
>> case I can imagine is that one of the functions accesses a file but
>> is too slow, and a subsequent SIGKILL causes some data loss.
>>
>> But with the current way *every* SIGTERM causes data loss for me.
>
> I did not follow this closely, but maybe this is hitting a problem in
> GNU/Linux?
>
> I compare with w32 where the shutdown process waits if some program
> has problem exiting.

That's the same on GNU/Linux, too.  When the system goes down all apps
receive a SIGTERM to shut down cleanly and after some seconds a SIGKILL
is sent to the ones that didn't terminate.

So IMO running `kill-emacs-hook' on SIGTERM (after saving all unsaved
buffers) is the right thing to do, because that's the hook which is
supposed to do all high-level cleanup stuff.

Concering these "inconsistent state" discussions: How about adding some
more text to the docstring of `kill-emacs-hook' explaining that user's
shouldn't put very time intensive functions there, and that in some
situations something may go wrong.

> Regarding Stefans suggestion the only useful thing to do is AFAICS to
> save some things to a file, so yes, there might be a problem - but
> probably not worse than doing nothing.

The saving on unsaved buffers is done with the current implementation,
too.  Stefan suggested to do that first, then to run `kill-emacs-hook'
and then to shutdown.  That's exactly what I expected before I
recognized that I'm losing data when shutting down the computer without
terminating the emacs daemon manually.

Bye,
Tassilo

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

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Sat, 24 Jan 2009 10:04:00 +0100
> Cc: emacs-devel@gnu.org
> 
> Concering these "inconsistent state" discussions: How about adding some
> more text to the docstring of `kill-emacs-hook' explaining that user's
> shouldn't put very time intensive functions there, and that in some
> situations something may go wrong.

If the Lisp infrastructure is in an inconsistent state, there's
nothing the user can do or avoid doing in `kill-emacs-hook' to avoid
trouble.

There are situations in Emacs when Lisp code simply cannot be run
safely.

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

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> If the Lisp infrastructure is in an inconsistent state, there's
> nothing the user can do or avoid doing in `kill-emacs-hook' to avoid
> trouble.
>
> There are situations in Emacs when Lisp code simply cannot be run
> safely.

It seems like the signal should just enqueue a "kill-emacs-event" of
some sort...

(isn't that how signals should be handled in general?)

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

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

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Sat, 24 Jan 2009 10:04:00 +0100
> Cc: emacs-devel@gnu.org
> 
> Concering these "inconsistent state" discussions: How about adding some
> more text to the docstring of `kill-emacs-hook' explaining that user's
> shouldn't put very time intensive functions there, and that in some
> situations something may go wrong.

If the Lisp infrastructure is in an inconsistent state, there's
nothing the user can do or avoid doing in `kill-emacs-hook' to avoid
trouble.

There are situations in Emacs when Lisp code simply cannot be run
safely.

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

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

IMHO we should not teach users to even do that.  

The safest thing to do is run
 emacsclient --eval "(save-buffers-kill-emacs)".

Relying on things getting saved properly on SIGTERM/SIGUSR* is just not a good
idea.

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

[Eli Zaretskii]

> Date: Fri, 23 Jan 2009 12:33:19 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: Tassilo Horn <tassilo@member.fsf.org>, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> 
> The safest thing to do is run
>  emacsclient --eval "(save-buffers-kill-emacs)".

That is, of course, much better than delivering a signal.

> Relying on things getting saved properly on SIGTERM/SIGUSR* is just not a good
> idea.

100% agreement.

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

[Jason Rumney]

Eli Zaretskii wrote:
> On balance, I would leave things as they are, i.e. don't run
> kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
> so only the minimum necessary cleanup should be in order.
>   

Another case for not running kill-emacs-hook for SIGTERM is that some 
elisp packages seem to get themselves into inconsistent states (semantic 
is terrible for this) where they throw errors from kill-emacs-hook, so 
the user is forced to kill emacs using SIGTERM. Changing SIGTERM to also 
run kill-emacs-hook would mean only SIGKILL can kill emacs in these 
circumstances.

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

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> Another case for not running kill-emacs-hook for SIGTERM is that some
> elisp packages seem to get themselves into inconsistent states (semantic
> is terrible for this) where they throw errors from kill-emacs-hook, so
> the user is forced to kill emacs using SIGTERM. Changing SIGTERM to also
> run kill-emacs-hook would mean only SIGKILL can kill emacs in these
> circumstances.

Well not really -- there are plenty of other signals to choose from!

-Miles

-- 
Barometer, n. An ingenious instrument which indicates what kind of weather we
are having.

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

[Richard M Stallman]

SIGTERM's handler could run from anywhere, even in code in
the interpreter during which interpreter data structures are
temporarily inconsistent.  So there is no telling what might go wrong
if it tries to run kill-emacs-hook.

    Maybe another option is to first perform the autosaves (like
    shut_down_emacs does), and then run a hook.  This way, no matter what
    the hook does, no data is lost.

I agree that is safer.

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

[grischka]

> On balance, I would leave things as they are, i.e. don't run
> kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
> so only the minimum necessary cleanup should be in order.

That seems to me like a quite twisted argumentation to say that
	"kill-emacs-hook"
should NOT be run because
	"After all, we are being killed ...".

Btw, with SIGINT emacs (GTK) quits like this
	Fatal Error (6)Abort
Is this a bug?

--- grischka

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

[Eli Zaretskii]

> Date: Fri, 23 Jan 2009 20:01:43 +0100
> From: grischka <grishka@gmx.de>
> CC:  emacs-devel@gnu.org
> 
> > On balance, I would leave things as they are, i.e. don't run
> > kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
> > so only the minimum necessary cleanup should be in order.
> 
> That seems to me like a quite twisted argumentation to say that
> 	"kill-emacs-hook"
> should NOT be run because
> 	"After all, we are being killed ...".

That's a perfect example of twisting someone else's argument by taking
it out of context and removing a few words.

> Btw, with SIGINT emacs (GTK) quits like this
> 	Fatal Error (6)Abort
> Is this a bug?

If that's the result of "kill -INT" from the shell prompt, then Emacs
should shut down.  Sounds like somewhere along the shutdown procedure
it hits a call to `abort'.  A backtrace would help.

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

[grischka]

Eli Zaretskii wrote:
>>> On balance, I would leave things as they are, i.e. don't run
>>> kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
>>> so only the minimum necessary cleanup should be in order.
>>
>> That seems to me like a quite twisted argumentation to say that
>> 	"kill-emacs-hook"
>> should NOT be run because
>> 	"After all, we are being killed ...".
> 
> That's a perfect example of twisting someone else's argument by taking
> it out of context and removing a few words.

Thanks.

>> Btw, with SIGINT emacs (GTK) quits like this
>> 	Fatal Error (6)Abort
>> Is this a bug?
> 
> If that's the result of "kill -INT" from the shell prompt, then Emacs
> should shut down.  Sounds like somewhere along the shutdown procedure
> it hits a call to `abort'.  A backtrace would help.
> 

Happens when pressing Ctrl-C after starting emacs at a xterm prompt.
IIRC to reproduce it it suffices to call 'pp' in a kill-emacs-hook.

Breakpoint 1, abort () at emacs.c:432
432	  kill (getpid (), SIGABRT);
(gdb) bt
#0  abort () at emacs.c:432
#1  0x0817db15 in Fsignal (error_symbol=138082153, data=155611005)
     at eval.c:1651
#2  0x0817dc38 in xsignal (error_symbol=138082153, data=155611005)
     at eval.c:1750
#3  0x0817dfde in xsignal3 (error_symbol=138082153, arg1=154631035, arg2=192,
     arg3=200) at eval.c:1781
#4  0x081a9a38 in scan_lists (from=25, count=1, depth=-2, sexpflag=0)
     at syntax.c:2805
#5  0x0817d833 in Ffuncall (nargs=4, args=0xbfa56350) at eval.c:3050
#6  0x081b2fd8 in Fbyte_code (bytestr=136910211, vector=136910228,
     maxdepth=<value optimized out>) at bytecode.c:678
#7  0x0817f683 in funcall_lambda (fun=136910164, nargs=1,
     arg_vector=0xbfa56498) at eval.c:3231
#8  0x0817d543 in Ffuncall (nargs=2, args=0xbfa56494) at eval.c:3101
#9  0x081b2fd8 in Fbyte_code (bytestr=154612923, vector=139722500,
     maxdepth=<value optimized out>) at bytecode.c:678
#10 0x0817f22c in Feval (form=155612917) at eval.c:2381
#11 0x0817fde1 in internal_lisp_condition_case (var=154765089,
     bodyform=155612917, handlers=155612869) at eval.c:1456
#12 0x081b3912 in Fbyte_code (bytestr=154613083, vector=154925740,
     maxdepth=<value optimized out>) at bytecode.c:868
#13 0x0817f683 in funcall_lambda (fun=154855964, nargs=0,
---Type <return> to continue, or q <return> to quit---
     arg_vector=0xbfa567c4) at eval.c:3231
#14 0x0817d543 in Ffuncall (nargs=1, args=0xbfa567c0) at eval.c:3101
#15 0x081b2fd8 in Fbyte_code (bytestr=154611523, vector=154577852,
     maxdepth=<value optimized out>) at bytecode.c:678
#16 0x0817f683 in funcall_lambda (fun=139231628, nargs=1,
     arg_vector=0xbfa568f8) at eval.c:3231
#17 0x0817d543 in Ffuncall (nargs=2, args=0xbfa568f4) at eval.c:3101
#18 0x081b2fd8 in Fbyte_code (bytestr=154612139, vector=152878316,
     maxdepth=<value optimized out>) at bytecode.c:678
#19 0x0817f683 in funcall_lambda (fun=139932676, nargs=2,
     arg_vector=0xbfa569b0) at eval.c:3231
#20 0x0817f8a2 in apply_lambda (fun=139932676, args=154748525, eval_flag=1)
     at eval.c:3155
#21 0x0817ef37 in Feval (form=154748517) at eval.c:2435
#22 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#23 0x081800c6 in Flet (args=154748261) at eval.c:1089
#24 0x0817f303 in Feval (form=154748213) at eval.c:2322
#25 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#26 0x0817f7a7 in funcall_lambda (fun=154748584, nargs=2,
     arg_vector=0xbfa56bd0) at eval.c:3224
#27 0x0817f8a2 in apply_lambda (fun=154748589, args=154745637, eval_flag=1)
     at eval.c:3155
#28 0x0817ef37 in Feval (form=154745613) at eval.c:2435
---Type <return> to continue, or q <return> to quit---
#29 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#30 0x0817f303 in Feval (form=155615749) at eval.c:2322
#31 0x0817f303 in Feval (form=155615725) at eval.c:2322
#32 0x0817f0b8 in Feval (form=154745597) at eval.c:2433
#33 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#34 0x081800c6 in Flet (args=154745589) at eval.c:1089
#35 0x0817f303 in Feval (form=154745453) at eval.c:2322
#36 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#37 0x081800c6 in Flet (args=154746821) at eval.c:1089
#38 0x0817f303 in Feval (form=154746781) at eval.c:2322
#39 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#40 0x0817f303 in Feval (form=155617557) at eval.c:2322
#41 0x0817f303 in Feval (form=155617533) at eval.c:2322
#42 0x0817f0b8 in Feval (form=154746765) at eval.c:2433
#43 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#44 0x0817f7a7 in funcall_lambda (fun=154743928, nargs=0,
     arg_vector=0xbfa57200) at eval.c:3224
#45 0x0817f8a2 in apply_lambda (fun=154743933, args=137866521, eval_flag=1)
     at eval.c:3155
#46 0x0817ef37 in Feval (form=154743981) at eval.c:2435
#47 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#48 0x0817f7a7 in funcall_lambda (fun=154744008, nargs=0,
     arg_vector=0xbfa57320) at eval.c:3224
---Type <return> to continue, or q <return> to quit---
#49 0x0817f8a2 in apply_lambda (fun=154744013, args=137866521, eval_flag=1)
     at eval.c:3155
#50 0x0817ef37 in Feval (form=154150709) at eval.c:2435
#51 0x0817f4ef in Fprogn (args=155611013) at eval.c:449
#52 0x0817f7a7 in funcall_lambda (fun=154150040, nargs=0,
     arg_vector=0xbfa574ec) at eval.c:3224
#53 0x0817d543 in Ffuncall (nargs=1, args=0xbfa574e8) at eval.c:3101
#54 0x0817e8e1 in run_hook_with_args (nargs=1, args=0xbfa574e8,
     cond=to_completion) at eval.c:2703
#55 0x0817eaa2 in Frun_hooks (nargs=1, args=0xbfa57584) at eval.c:2566
#56 0x0817d6ee in Ffuncall (nargs=2, args=0xbfa57580) at eval.c:3025
#57 0x0817e769 in call1 (fn=138005017, arg1=138054393) at eval.c:2829
#58 0x0810d535 in Fkill_emacs (arg=137866521) at emacs.c:2151
#59 0x081124b5 in interrupt_signal (signalnum=2) at keyboard.c:10954
#60 <signal handler called>
#61 0xb8059430 in __kernel_vsyscall ()
#62 0xb75f8bcd in select () from /lib/tls/i686/cmov/libc.so.6
#63 0x081b926a in wait_reading_process_output (time_limit=0, microsecs=0,
     read_kbd=-1, do_display=1, wait_for_cell=137866521, wait_proc=0x0,
     just_wait_proc=0) at process.c:4452
#64 0x0811a991 in read_char (commandflag=1, nmaps=6, maps=0xbfa57f30,
     prev_event=137866521, used_mouse_menu=0xbfa58050, end_time=0x0)
     at keyboard.c:4058
---Type <return> to continue, or q <return> to quit---
#65 0x0811d1a2 in read_key_sequence (keybuf=0xbfa58104, bufsize=30,
     prompt=137866521, dont_downcase_last=0, can_return_switch_frame=1,
     fix_current_buffer=1) at keyboard.c:9365
#66 0x0811ee03 in command_loop_1 () at keyboard.c:1631
#67 0x0817cb40 in internal_condition_case (bfun=0x811ec20 <command_loop_1>,
     handlers=137910681, hfun=0x8117bc0 <cmd_error>) at eval.c:1511
#68 0x08117115 in command_loop_2 () at keyboard.c:1348
#69 0x0817cc1a in internal_catch (tag=137905657,
     func=0x81170f0 <command_loop_2>, arg=137866521) at eval.c:1247
#70 0x08117a0f in command_loop () at keyboard.c:1327
#71 0x08117dcb in recursive_edit_1 () at keyboard.c:942
#72 0x08117f14 in Frecursive_edit () at keyboard.c:1004
#73 0x0810e777 in main (argc=1, argv=0xbfa58784) at emacs.c:1852

Lisp Backtrace:
"scan-lists" (0xbfa56354)
"down-list" (0xbfa56498)
"byte-code" (0xbfa5652c)
"pp-buffer" (0xbfa567c4)
"pp-to-string" (0xbfa568f8)
"pp" (0xbfa569b0)
"let" (0xbfa56b50)
"prj-print-list" (0xbfa56bd0)
---Type <return> to continue, or q <return> to quit---
"progn" (0xbfa56d10)
"if" (0xbfa56d90)
"when" (0xbfa56e10)
"let" (0xbfa56f00)
"let" (0xbfa56ff0)
"progn" (0xbfa57080)
"if" (0xbfa57100)
"when" (0xbfa57180)
"prj-saveconfig" (0xbfa57200)
"prj-saveall" (0xbfa57320)
"prj-on-kill" (0xbfa574ec)
"run-hooks" (0xbfa57584)
(gdb)

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

[Eli Zaretskii]

> Date: Sat, 24 Jan 2009 15:16:42 +0100
> From: grischka <grishka@gmx.de>
> CC: emacs-devel@gnu.org
> 
> >> Btw, with SIGINT emacs (GTK) quits like this
> >> 	Fatal Error (6)Abort
> >> Is this a bug?
> > 
> > If that's the result of "kill -INT" from the shell prompt, then Emacs
> > should shut down.  Sounds like somewhere along the shutdown procedure
> > it hits a call to `abort'.  A backtrace would help.
> > 
> 
> Happens when pressing Ctrl-C after starting emacs at a xterm prompt.

Pressing Ctrl-C where?  Emacs redefines SIGINT so that it is produced
by C-g, not by C-c (because the latter is used in many key sequences),
so I presume you don't mean typing Ctrl-C into the Emacs window.  But
then where did you type it?

Also, by "starting emacs at a xterm prompt", do you mean "emacs -nw"
or do you mean a GUI session started at the shell prompt?

> IIRC to reproduce it it suffices to call 'pp' in a kill-emacs-hook.

You mean, call 'pp' in a kill-emacs-hook and _then_ deliver a SIGINT?
Or do you mean that having `pp' called from kill-emacs-hook will cause
the abort even if Emacs is shut down normally, via "C-c C-c"?

> "prj-print-list" (0xbfa56bd0)
> "progn" (0xbfa56d10)
> "if" (0xbfa56d90)
> "when" (0xbfa56e10)
> "let" (0xbfa56f00)
> "let" (0xbfa56ff0)
> "progn" (0xbfa57080)
> "if" (0xbfa57100)
> "when" (0xbfa57180)
> "prj-saveconfig" (0xbfa57200)
> "prj-saveall" (0xbfa57320)
> "prj-on-kill" (0xbfa574ec)
> "run-hooks" (0xbfa57584)
> (gdb)

What are those prj-* functions?

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

[grischka]

Eli Zaretskii wrote:
> Pressing Ctrl-C where? Emacs redefines SIGINT so that it is produced
> by C-g, not by C-c (because the latter is used in many key sequences),
> so I presume you don't mean typing Ctrl-C into the Emacs window.  But
> then where did you type it?

In the xterm.

> Also, by "starting emacs at a xterm prompt", do you mean "emacs -nw"
> or do you mean a GUI session started at the shell prompt?

$ emacs<ret>

>> IIRC to reproduce it it suffices to call 'pp' in a kill-emacs-hook.
>
> You mean, call 'pp' in a kill-emacs-hook and _then_ deliver a SIGINT?

Yes.

> Or do you mean that having `pp' called from kill-emacs-hook will cause
> the abort even if Emacs is shut down normally, via "C-c C-c"?

No.

>> "prj-print-list" (0xbfa56bd0)
>> "progn" (0xbfa56d10)
>> "if" (0xbfa56d90)
>> "when" (0xbfa56e10)
>> "let" (0xbfa56f00)
>> "let" (0xbfa56ff0)
>> "progn" (0xbfa57080)
>> "if" (0xbfa57100)
>> "when" (0xbfa57180)
>> "prj-saveconfig" (0xbfa57200)
>> "prj-saveall" (0xbfa57320)
>> "prj-on-kill" (0xbfa574ec)
>> "run-hooks" (0xbfa57584)
>> (gdb)
>
> What are those prj-* functions?
>

"eproject", available at Tom Tromey's ELPA.

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

[Eli Zaretskii]

> Date: Sat, 24 Jan 2009 18:56:17 +0100
> From: grischka <grishka@gmx.de>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Pressing Ctrl-C where? Emacs redefines SIGINT so that it is produced
> > by C-g, not by C-c (because the latter is used in many key sequences),
> > so I presume you don't mean typing Ctrl-C into the Emacs window.  But
> > then where did you type it?
> 
> In the xterm.

It aborts in eval.c here:

  if (gc_in_progress || waiting_for_input)
    abort ();

Can you see which one of gc_in_progress and waiting_for_input is
non-zero?

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

[grischka]

Eli Zaretskii wrote:
>> Date: Sat, 24 Jan 2009 18:56:17 +0100
>> From: grischka <grishka@gmx.de>
>> CC: emacs-devel@gnu.org
>>
>> Eli Zaretskii wrote:
>>> Pressing Ctrl-C where? Emacs redefines SIGINT so that it is produced
>>> by C-g, not by C-c (because the latter is used in many key sequences),
>>> so I presume you don't mean typing Ctrl-C into the Emacs window.  But
>>> then where did you type it?
>> In the xterm.
> 
> It aborts in eval.c here:
> 
>   if (gc_in_progress || waiting_for_input)
>     abort ();
> 

Here too.

> Can you see which one of gc_in_progress and waiting_for_input is
> non-zero?
> 

I'd bet for "waiting_for_input". However the problem starts earlier at:

#4  0x081a9a78 in scan_lists (from=8, count=1, depth=-1, sexpflag=0)
     at syntax.c:2805

where it hits the "lose" label.  And no, I haven't figured out how
this happens.

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

[Eli Zaretskii]

> Date: Sat, 24 Jan 2009 20:11:23 +0100
> From: grischka <grishka@gmx.de>
> CC: emacs-devel@gnu.org
> 
> >   if (gc_in_progress || waiting_for_input)
> >     abort ();
> > 
> 
> Here too.
> 
> > Can you see which one of gc_in_progress and waiting_for_input is
> > non-zero?
> > 
> 
> I'd bet for "waiting_for_input".

Maybe; but I don't think Emacs should wait for input in the middle of
processing.  It only does so when it is idle.

> However the problem starts earlier at:
> 
> #4  0x081a9a78 in scan_lists (from=8, count=1, depth=-1, sexpflag=0)
>      at syntax.c:2805
> 
> where it hits the "lose" label.

That just makes it signal an error, which should not cause an abort.

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

[grischka]

Eli Zaretskii wrote:
>> Date: Sat, 24 Jan 2009 20:11:23 +0100
>> From: grischka <grishka@gmx.de>
>> CC: emacs-devel@gnu.org
>>
>>>   if (gc_in_progress || waiting_for_input)
>>>     abort ();
>>>
>> Here too.
>>
>>> Can you see which one of gc_in_progress and waiting_for_input is
>>> non-zero?
>>>
>> I'd bet for "waiting_for_input".
> 
> Maybe; but I don't think Emacs should wait for input in the middle of
> processing.  It only does so when it is idle.

If that is right then the flag state must be wrong.

> 
>> However the problem starts earlier at:
>>
>> #4  0x081a9a78 in scan_lists (from=8, count=1, depth=-1, sexpflag=0)
>>      at syntax.c:2805
>>
>> where it hits the "lose" label.
> 
> That just makes it signal an error, which should not cause an abort.
> 

Okay, so it's two bugs.

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

[Stefan Monnier]

> We may also delay it indefinitely if we run Lisp, because that could
> infloop, especially if our internal data structures are unstable.

What makes you think our data structures might be unstable when we
get SIGTERM?  AFAIK this signal is only received when some external
process decides that Emacs should stop, so data structures should be
just as stable as when we receive SIGUSRn.

> If SIGTERM is used to programmatically shut down Emacs, I think it's
> rather a conceptual bug in whatever uses SIGTERM for that purpose.

Huh?  SIGTERM is *the canonical way* to programmatically shut down an
application via a signal.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 24 Jan 2009 15:32:43 -0500
> Cc: tassilo@member.fsf.org, emacs-devel@gnu.org
> 
> > We may also delay it indefinitely if we run Lisp, because that could
> > infloop, especially if our internal data structures are unstable.
> 
> What makes you think our data structures might be unstable when we
> get SIGTERM?

Because of what you yourself wrote:

> AFAIK this signal is only received when some external process
> decides that Emacs should stop

An external process can decide that Emacs should stop whenever it
wants to, and Emacs could be in the middle of GC, for example.

> so data structures should be just as stable as when we receive
> SIGUSRn.

I wasn't comparing with SIGUSRn when I wrote the above.

> > If SIGTERM is used to programmatically shut down Emacs, I think it's
> > rather a conceptual bug in whatever uses SIGTERM for that purpose.
> 
> Huh?  SIGTERM is *the canonical way* to programmatically shut down an
> application via a signal.

From _outside_ Emacs, yes.  Which isn't the case here.

Anyway, Dan suggested a better way long ago, so it's IMO pointless to
continue this argument.

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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > If SIGTERM is used to programmatically shut down Emacs, I think it's
>> > rather a conceptual bug in whatever uses SIGTERM for that purpose.
>> 
>> Huh?  SIGTERM is *the canonical way* to programmatically shut down an
>> application via a signal.
>
> From _outside_ Emacs, yes.  Which isn't the case here.

When emacs is started with --daemon users (me!) forget to kill it
manually, and so init does it when the whole system shuts down.  That's
not from _outside_ Emacs?

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

Bye,
Tassilo

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

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> 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.

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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> 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 <200901232033.n0NKXJ3p017121@rodan.ics.uci.edu>
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

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

[Stefan Monnier]

>> > We may also delay it indefinitely if we run Lisp, because that could
>> > infloop, especially if our internal data structures are unstable.
>> What makes you think our data structures might be unstable when we
>> get SIGTERM?
> Because of what you yourself wrote:
>> AFAIK this signal is only received when some external process
>> decides that Emacs should stop
> An external process can decide that Emacs should stop whenever it
> wants to, and Emacs could be in the middle of GC, for example.

But as I said repeatedly in this thread it's irrelevant, because in
order for it to run kill-emacs-hook, this signal should not be handed
from its signal handler but from the usual input handling, just
like SIGUSRn.  So data-structures should be just fine.

>> > If SIGTERM is used to programmatically shut down Emacs, I think it's
>> > rather a conceptual bug in whatever uses SIGTERM for that purpose.
>> Huh?  SIGTERM is *the canonical way* to programmatically shut down an
>> application via a signal.
>> From _outside_ Emacs, yes.  Which isn't the case here.
> Anyway, Dan suggested a better way long ago, so it's IMO pointless to
> continue this argument.

No, it's an alternative solution to "how do I kill the daemon".
I still think that sending the SIGTERM signal should run
kill-emacs-hook, regardless.


        Stefan

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

[Stefan Monnier]

>> On balance, I would leave things as they are, i.e. don't run
>> kill-emacs-hook when we get SIGTERM.  After all, we are being killed,
>> so only the minimum necessary cleanup should be in order.
> Another case for not running kill-emacs-hook for SIGTERM is that some elisp
> packages seem to get themselves into inconsistent states (semantic is
> terrible for this) where they throw errors from kill-emacs-hook, so the user
> is forced to kill emacs using SIGTERM. Changing SIGTERM to also run
> kill-emacs-hook would mean only SIGKILL can kill emacs in
> these circumstances.

I'd think that throwing errors from kill-emacs-hook should not prevent
Emacs from exiting.  Can someone look into this and fix the problem?


        Stefan

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

[grischka]

From:     Tassilo Horn
 > I don't get what could be so dangerous running a user-defined hook after
 > all buffers have been saved, as Stefan suggested.  The worst case I can
 > imagine is that one of the functions accesses a file but is too slow,
 > and a subsequent SIGKILL causes some data loss.

Actually it requires only three lines to get something that seems to
work quite nicely, at least for demonstration purposes.

Replace one line in emacs.c:~1315:

-  signal (SIGTERM, fatal_error_signal);
+  add_user_signal (SIGTERM, "sigterm");

and add some lisp to catch the signal (can be put into .emacs, to begin with)

(define-key special-event-map [sigterm] 'sigterm-handler)
(defun sigterm-handler () (interactive) (kill-emacs))

Where kill-emacs will also run the kill-emacs-hooks in a safe way, as intended.

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

[Stefan Monnier]

> Actually it requires only three lines to get something that seems to
> work quite nicely, at least for demonstration purposes.

> Replace one line in emacs.c:~1315:

> -  signal (SIGTERM, fatal_error_signal);
> +  add_user_signal (SIGTERM, "sigterm");

> and add some lisp to catch the signal (can be put into .emacs, to begin with)

> (define-key special-event-map [sigterm] 'sigterm-handler)
> (defun sigterm-handler () (interactive) (kill-emacs))

> Where kill-emacs will also run the kill-emacs-hooks in a safe way, as intended.

Yes, I think this is the right way to do it.  The only change I'd like
to do is to do the autosaves as before in the signal handler before
passing on the signal through the normal input handling (i.e. before
running kill-emacs-hook).


        Stefan

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

[grischka]

Stefan Monnier wrote:
> Yes, I think this is the right way to do it.  The only change I'd like
> to do is to do the autosaves as before in the signal handler before
> passing on the signal through the normal input handling (i.e. before
> running kill-emacs-hook).

Well, in an ideal world the signal handler could just set the quit-flag
which would interrupt running lisp code and in consequence allow the
sigterm EVENT being handled reliably always, such that things like
autosave could be done from lisp as well.

I don't know however whether emacs' "quit-world" is ideal enough for
this scenario.

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

[Stefan Monnier]

>> Yes, I think this is the right way to do it.  The only change I'd like
>> to do is to do the autosaves as before in the signal handler before
>> passing on the signal through the normal input handling (i.e. before
>> running kill-emacs-hook).

> Well, in an ideal world the signal handler could just set the quit-flag
> which would interrupt running lisp code and in consequence allow the
> sigterm EVENT being handled reliably always, such that things like
> autosave could be done from lisp as well.

No, we want to do the autosave directly from the signal handler (like we
do currently), because the Lisp world might be so completely messed up
that even the quit-flag would never be noticed.


        Stefan