bug#28542: Temporary failure in name resolution while quitting emacs

bug#28542: Temporary failure in name resolution while quitting emacs

[Baylis Shanks]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

I had an http address open in a buffer (i think i closed that buffer), and then i disconnected from the internet and then attempted to quit emacs. Emacs would not quit; when i attempted to quit it, a message involving 'open-network-stream' and 'temporary failure in name resolution' would be displayed in *messages* and then nothing would happen.


Manually opening an elisp buffer and using setq to remove save-place-kill-emacs-hook from kill-emacs-hook solved the problem.


I think there are really two bugs here;


1) whatever save-place-kill-emacs-hook is doing should be robust to 'temporary failure in name resolution' errors


2) more importantly, if there is an error in something called from kill-emacs-hook, emacs should not just return to normal functioning (without quitting), but rather should give the user a choice of whether to continue to quit or not (if continue to quit is chosen, the remaining items in kill-emacs-hook should be called). It's really frustrating to a user when the user cannot figure out how to quit a program.


[-- Attachment #2: Type: text/html, Size: 1601 bytes --]

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Baylis Shanks <bshanks3@hotmail.com> writes:

> I had an http address open in a buffer (i think i closed that buffer),
> and then i disconnected from the internet and then attempted to quit
> emacs. Emacs would not quit; when i attempted to quit it, a message
> involving 'open-network-stream' and 'temporary failure in name
> resolution' would be displayed in *messages* and then nothing would
> happen.
>
> Manually opening an elisp buffer and using setq to remove
> save-place-kill-emacs-hook from kill-emacs-hook solved the problem.

(This bug report unfortunately got no response at the time.)

I'm guessing you don't have a backtrace here to let us see what the code
in question was after all this time?

> 2) more importantly, if there is an error in something called from
> kill-emacs-hook, emacs should not just return to normal functioning
> (without quitting), but rather should give the user a choice of
> whether to continue to quit or not (if continue to quit is chosen, the
> remaining items in kill-emacs-hook should be called). It's really
> frustrating to a user when the user cannot figure out how to quit a
> program.

I agree.  To reproduce:

(push (lambda () (error "this is an error")) kill-emacs-hook)
`C-x C-c'

Result: Just an error message, and you can't kill Emacs.  I think it
should catch the error and ask whether to continue anyway.  Opinions?

The flow control here is a bit odd, though.  `save-buffers-kill-emacs'
calls Fkill_emacs, which starts:

DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P",
[...]
  /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
     set.  */
  waiting_for_input = 0;
  if (noninteractive)
    safe_run_hooks (Qkill_emacs_hook);
  else
    run_hook (Qkill_emacs_hook);

Is this bit done from the C level because of that waiting_for_input
setting?  And...  I don't understand the comment -- the `error' (which
calls signal?) doesn't abort Emacs?  Anybody?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Nov 2020 11:53:24 +0100
> Cc: 28542@debbugs.gnu.org
> 
> > 2) more importantly, if there is an error in something called from
> > kill-emacs-hook, emacs should not just return to normal functioning
> > (without quitting), but rather should give the user a choice of
> > whether to continue to quit or not (if continue to quit is chosen, the
> > remaining items in kill-emacs-hook should be called). It's really
> > frustrating to a user when the user cannot figure out how to quit a
> > program.
> 
> I agree.  To reproduce:
> 
> (push (lambda () (error "this is an error")) kill-emacs-hook)
> `C-x C-c'
> 
> Result: Just an error message, and you can't kill Emacs.  I think it
> should catch the error and ask whether to continue anyway.  Opinions?

The ELisp manual says ab out kill-emacs-hook:

     Because ‘kill-emacs’ can be called in situations where user
     interaction is impossible (e.g., when the terminal is
     disconnected), functions on this hook should not attempt to
     interact with the user.  If you want to interact with the user when
     Emacs is shutting down, use ‘kill-emacs-query-functions’, described
     below.

So I don't think we can safely ask whether to continue.  We could
either use safe_run_hooks, as we do in the noninteractive case (thus
silently ignoring errors in this hook even if we do have a means to
communicate with the user), or maybe move the offending function to
kill-emacs-query-functions.  Or try a more limited solution of
ensuring this particular function doesn't signal an error, or catches
it and returns.

> The flow control here is a bit odd, though.  `save-buffers-kill-emacs'
> calls Fkill_emacs, which starts:
> 
> DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P",
> [...]
>   /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
>      set.  */
>   waiting_for_input = 0;
>   if (noninteractive)
>     safe_run_hooks (Qkill_emacs_hook);
>   else
>     run_hook (Qkill_emacs_hook);
> 
> Is this bit done from the C level because of that waiting_for_input
> setting?  And...  I don't understand the comment -- the `error' (which
> calls signal?) doesn't abort Emacs?  Anybody?

I think the comment has this exact scenario in mind: if we don't make
sure waiting_for_input is zero, and the hook just happens to signal an
error, Emacs will dump core.

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The ELisp manual says ab out kill-emacs-hook:
>
>      Because ‘kill-emacs’ can be called in situations where user
>      interaction is impossible (e.g., when the terminal is
>      disconnected), functions on this hook should not attempt to
>      interact with the user.  If you want to interact with the user when
>      Emacs is shutting down, use ‘kill-emacs-query-functions’, described
>      below.
>
> So I don't think we can safely ask whether to continue.

I don't quite interpret it that way -- this only says that if your
intention is to communicate with the user, then use
`kill-emacs-query-functions'.

The current situation is that if you have an error in `kill-emacs-hook'
(and you're running an interactive Emacs), then you can't kill Emacs at
all.  Adding a query to the user about what to do is an improvement, and
won't regress anything.

> We could either use safe_run_hooks, as we do in the noninteractive
> case (thus silently ignoring errors in this hook even if we do have a
> means to communicate with the user), or maybe move the offending
> function to kill-emacs-query-functions.  Or try a more limited
> solution of ensuring this particular function doesn't signal an error,
> or catches it and returns.

I'm a bit leery at doing anything automatically (either ignoring the
error or re-running it from a different context).  The hook may be, for
instance, writing stuff to a data file and then clearing out some
structures, and re-writing the stuff may clear the data, for instance.

Only the user should be making a judgement call in the error situation
here.

>> The flow control here is a bit odd, though.  `save-buffers-kill-emacs'
>> calls Fkill_emacs, which starts:
>> 
>> DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P",
>> [...]
>>   /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
>>      set.  */
>>   waiting_for_input = 0;
>>   if (noninteractive)
>>     safe_run_hooks (Qkill_emacs_hook);
>>   else
>>     run_hook (Qkill_emacs_hook);
>> 
>> Is this bit done from the C level because of that waiting_for_input
>> setting?  And...  I don't understand the comment -- the `error' (which
>> calls signal?) doesn't abort Emacs?  Anybody?
>
> I think the comment has this exact scenario in mind: if we don't make
> sure waiting_for_input is zero, and the hook just happens to signal an
> error, Emacs will dump core.

Oh, I interpreted it the opposite way -- that "waiting_for_input = 0" is
setting it.  To zero.  But it means "isn't cleared"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com,  28542@debbugs.gnu.org
> Date: Wed, 02 Dec 2020 10:47:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The ELisp manual says ab out kill-emacs-hook:
> >
> >      Because ‘kill-emacs’ can be called in situations where user
> >      interaction is impossible (e.g., when the terminal is
> >      disconnected), functions on this hook should not attempt to
> >      interact with the user.  If you want to interact with the user when
> >      Emacs is shutting down, use ‘kill-emacs-query-functions’, described
> >      below.
> >
> > So I don't think we can safely ask whether to continue.
> 
> I don't quite interpret it that way -- this only says that if your
> intention is to communicate with the user, then use
> `kill-emacs-query-functions'.

But your suggestion was to ask the user whether to continue -- doesn't
that qualify as "communicating with the user"?

> The current situation is that if you have an error in `kill-emacs-hook'
> (and you're running an interactive Emacs), then you can't kill Emacs at
> all.  Adding a query to the user about what to do is an improvement, and
> won't regress anything.

That's true, but I don't suggest to do nothing, I was trying to find a
better way, one which would work also when there's no way to get any
answer from the user.

> > We could either use safe_run_hooks, as we do in the noninteractive
> > case (thus silently ignoring errors in this hook even if we do have a
> > means to communicate with the user), or maybe move the offending
> > function to kill-emacs-query-functions.  Or try a more limited
> > solution of ensuring this particular function doesn't signal an error,
> > or catches it and returns.
> 
> I'm a bit leery at doing anything automatically (either ignoring the
> error or re-running it from a different context).  The hook may be, for
> instance, writing stuff to a data file and then clearing out some
> structures, and re-writing the stuff may clear the data, for instance.
> 
> Only the user should be making a judgement call in the error situation
> here.

Then perhaps waiting for the response for some finite time would cover
the cases where the user cannot answer the question?

> >>   /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
> >>      set.  */
> >>   waiting_for_input = 0;
> >>   if (noninteractive)
> >>     safe_run_hooks (Qkill_emacs_hook);
> >>   else
> >>     run_hook (Qkill_emacs_hook);
> >> 
> >> Is this bit done from the C level because of that waiting_for_input
> >> setting?  And...  I don't understand the comment -- the `error' (which
> >> calls signal?) doesn't abort Emacs?  Anybody?
> >
> > I think the comment has this exact scenario in mind: if we don't make
> > sure waiting_for_input is zero, and the hook just happens to signal an
> > error, Emacs will dump core.
> 
> Oh, I interpreted it the opposite way -- that "waiting_for_input = 0" is
> setting it.  To zero.  But it means "isn't cleared"?

Yes, setting to zero is "resetting".  The abort happens if the value
is non-zero.

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The ELisp manual says ab out kill-emacs-hook:
>> >
>> >      Because ‘kill-emacs’ can be called in situations where user
>> >      interaction is impossible (e.g., when the terminal is
>> >      disconnected), functions on this hook should not attempt to
>> >      interact with the user.  If you want to interact with the user when
>> >      Emacs is shutting down, use ‘kill-emacs-query-functions’, described
>> >      below.
>> >
>> > So I don't think we can safely ask whether to continue.
>> 
>> I don't quite interpret it that way -- this only says that if your
>> intention is to communicate with the user, then use
>> `kill-emacs-query-functions'.
>
> But your suggestion was to ask the user whether to continue -- doesn't
> that qualify as "communicating with the user"?

It does.  But the manual talks about intent -- "if you want to interact"
-- but doesn't prohibit Emacs itself from interacting with the user.
Obviously an error doesn't happen by intent.

> Then perhaps waiting for the response for some finite time would cover
> the cases where the user cannot answer the question?

Do you mean in the noninteractive case?  I don't propose to change
anything unless interactive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com,  28542@debbugs.gnu.org
> Date: Thu, 03 Dec 2020 09:47:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > The ELisp manual says ab out kill-emacs-hook:
> >> >
> >> >      Because ‘kill-emacs’ can be called in situations where user
> >> >      interaction is impossible (e.g., when the terminal is
> >> >      disconnected), functions on this hook should not attempt to
> >> >      interact with the user.  If you want to interact with the user when
> >> >      Emacs is shutting down, use ‘kill-emacs-query-functions’, described
> >> >      below.
> >> >
> >> > So I don't think we can safely ask whether to continue.
> >> 
> >> I don't quite interpret it that way -- this only says that if your
> >> intention is to communicate with the user, then use
> >> `kill-emacs-query-functions'.
> >
> > But your suggestion was to ask the user whether to continue -- doesn't
> > that qualify as "communicating with the user"?
> 
> It does.  But the manual talks about intent -- "if you want to interact"
> -- but doesn't prohibit Emacs itself from interacting with the user.
> Obviously an error doesn't happen by intent.

I think the manual talks about situations where the communications are
impossible.  What do we do in that case?

> > Then perhaps waiting for the response for some finite time would cover
> > the cases where the user cannot answer the question?
> 
> Do you mean in the noninteractive case?  I don't propose to change
> anything unless interactive.

No, I was talking about the interactive case.  Are you assuming that
in the interactive case it is always possible to ask a question and
get a response from the user?

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, I was talking about the interactive case.  Are you assuming that
> in the interactive case it is always possible to ask a question and
> get a response from the user?

Isn't that usually the case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> No, I was talking about the interactive case.  Are you assuming that
>> in the interactive case it is always possible to ask a question and
>> get a response from the user?
>
> Isn't that usually the case?

Iʼd say most of the time, but given the (incomprehensible to me)
enthusiasm for running 'emacs --daemon', I wouldn't be surprised if
there were cases where itʼs not true.

Robert

bug#28542: Temporary failure in name resolution while quitting emacs

[Glenn Morris]

Robert Pluim wrote:

>>> No, I was talking about the interactive case.  Are you assuming that
>>> in the interactive case it is always possible to ask a question and
>>> get a response from the user?
>>
>> Isn't that usually the case?
>
> Iʼd say most of the time, but given the (incomprehensible to me)
> enthusiasm for running 'emacs --daemon', I wouldn't be surprised if
> there were cases where itʼs not true.

See https://debbugs.gnu.org/13697

Putting anything on kill-emacs-hook that may need user input will hang
Emacs in certain circumstances. (The lispref text on this reads clearly to me.)

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> See https://debbugs.gnu.org/13697
>
> Putting anything on kill-emacs-hook that may need user input will hang
> Emacs in certain circumstances. (The lispref text on this reads clearly to me.)

I'm not quite sure I see the relevance here -- any prompt that Emacs
issues may hang Emacs in some circumstances, and there's nothing special
about adding a prompt here.

(I agree that there should be a way to make Emacs non-interactive -- I
run Emacs as a remote daemon a lot, and slapping down all the
interactive queries that pepper the Emacs code is a chore.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com,  28542@debbugs.gnu.org
> Date: Fri, 04 Dec 2020 10:34:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, I was talking about the interactive case.  Are you assuming that
> > in the interactive case it is always possible to ask a question and
> > get a response from the user?
> 
> Isn't that usually the case?

Usually, yes.  But what about the "unusual" cases?  If they exist,
waiting for an answer there will leave Emacs hung.  I proposed to use
a timeout for those cases.

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Usually, yes.  But what about the "unusual" cases?  If they exist,
> waiting for an answer there will leave Emacs hung.  I proposed to use
> a timeout for those cases.

Sure, a prompt with a timeout would be fine by me.

Looking at the code again:

  /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
     set.  */
  waiting_for_input = 0;
  if (noninteractive)
    safe_run_hooks (Qkill_emacs_hook);
  else
    run_hook (Qkill_emacs_hook);

Would it make sense to create a new Lisp-level function to do the
run-hook/prompting stuff, and call out to that?  And move the setting of
waiting_for_input into the "then" branch?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com,  28542@debbugs.gnu.org
> Date: Sun, 06 Dec 2020 13:50:14 +0100
> 
> Sure, a prompt with a timeout would be fine by me.
> 
> Looking at the code again:
> 
>   /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
>      set.  */
>   waiting_for_input = 0;
>   if (noninteractive)
>     safe_run_hooks (Qkill_emacs_hook);
>   else
>     run_hook (Qkill_emacs_hook);
> 
> Would it make sense to create a new Lisp-level function to do the
> run-hook/prompting stuff, and call out to that?  And move the setting of
> waiting_for_input into the "then" branch?

I think it'd be good to have a run_hook_with_timeout function, yes.
Whether it should be exposed to Lisp, I'm less certain: what would be
the use case that isn't this single place?

As for zeroing waiting_for_input: it's almost certainly shouldn't be
part of that, since it should always be zero when Emacs signals an
error.  We do this here because this might be exiting due to a fatal
signal, in which case all bets are off, and we should better be safe
than sorry.

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it'd be good to have a run_hook_with_timeout function, yes.
> Whether it should be exposed to Lisp, I'm less certain: what would be
> the use case that isn't this single place?

It is somewhat special-purpose; yes.  On the other hand, implementing it
in Lisp is a lot easier, and I guess I could envision people actually
using it for other things, too?  So I just put it in subr.el.  (But I
did not document it in the manual, because it does not seem to warrant
that.)

Pushed to the trunk now and the test case seems to work fine.

> As for zeroing waiting_for_input: it's almost certainly shouldn't be
> part of that, since it should always be zero when Emacs signals an
> error.  We do this here because this might be exiting due to a fatal
> signal, in which case all bets are off, and we should better be safe
> than sorry.

I'm not quite sure I'm reading this paragraph right -- I'm not sure what
"that" in "shouldn't be part of that" refers to here.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28542: Temporary failure in name resolution while quitting emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com,  28542@debbugs.gnu.org
> Date: Mon, 07 Dec 2020 15:43:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think it'd be good to have a run_hook_with_timeout function, yes.
> > Whether it should be exposed to Lisp, I'm less certain: what would be
> > the use case that isn't this single place?
> 
> It is somewhat special-purpose; yes.  On the other hand, implementing it
> in Lisp is a lot easier, and I guess I could envision people actually
> using it for other things, too?  So I just put it in subr.el.  (But I
> did not document it in the manual, because it does not seem to warrant
> that.)

Beware: calling Lisp when we are about to crash due to a fatal signal
could cause more problems than it solves.

> > As for zeroing waiting_for_input: it's almost certainly shouldn't be
> > part of that, since it should always be zero when Emacs signals an
> > error.  We do this here because this might be exiting due to a fatal
> > signal, in which case all bets are off, and we should better be safe
> > than sorry.
> 
> I'm not quite sure I'm reading this paragraph right -- I'm not sure what
> "that" in "shouldn't be part of that" refers to here.  :-)

"That" refers to the function you wanted to provide.

bug#28542: Temporary failure in name resolution while quitting emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Beware: calling Lisp when we are about to crash due to a fatal signal
> could cause more problems than it solves.

Indeed, but it's a hook runner -- it will almost inevitably call other
Lisp functions.

But by default, kill-emacs-hook is nil, so perhaps it would be a good
idea to check that first, and avoid calling the function if that's the
case.  I'll make that change.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no