On 2022-11-04 00:00, Eli Zaretskii wrote:
We need to establish what is the
source of SIGHUP in these cases. "These cases" mean, AFAIU, the
situations where Emacs launched an async subprocess to do native
compilation (which is another Emacs process in a --batch session), and
the parent Emacs session is terminated by the user before the async
compilation runs to completion. Would the child Emacs process get
SIGHUP in this scenario?
Hard for me to say. It's a messy area, with kernels (and Emacs itself)
sending SIGHUP on various whims.
Does the attached patch fix things? It builds on your commit
190a6853708ab22072437f6ebd93beb3ec1a9ce6 dated 2020-12-04; I don't know
why that earlier patch was installed, but it would seem to apply to
SIGHUP and SIGTERM as well as it applies to SIGINT.diff --git a/src/emacs.c b/src/emacs.c
index 1b2aa9442b..92e2299a04 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -432,9 +432,9 @@ terminate_due_to_signal (int sig, int backtrace_limit)
if (sig == SIGTERM || sig == SIGHUP || sig == SIGINT)
{
/* Avoid abort in shut_down_emacs if we were interrupted
- by SIGINT in noninteractive usage, as in that case we
+ in noninteractive usage, as in that case we
don't care about the message stack. */
- if (sig == SIGINT && noninteractive)
+ if (noninteractive)
clear_message_stack ();
Fkill_emacs (make_fixnum (sig), Qnil);
}
