bug#2520: 23.0.91; Dies on SIGHUP

bug#2520: 23.0.91; Dies on SIGHUP

[pent]

To reproduce:

1) emacs -Q. Emacs process starts.

2) pkill -s 1 emacs. Emacs process dies.

The more appropriate behavior would be to reload the configuration
without restarting (i.e. reread X resource values). This behavior
would be especially useful for the daemon mode. I'm pretty sure
previous snapshot versions used to work that way.

I'm ready to provide any additional info,
Andrey 

In GNU Emacs 23.0.91.1 (i486-pc-linux-gnu, GTK+ Version 2.12.12)
 of 2009-02-28 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20090228-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.91/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.91/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ru_RU.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  delete-selection-mode: t
  show-paren-mode: t
  pc-selection-mode: t
  pretty-control-l-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done
Loading /etc/emacs/site-start.d/50w3m-el-snapshot.el (source)...done
Loading /etc/emacs/site-start.d/51debian-el.el (source)...done
Loading /etc/emacs/site-start.d/99pp-c-l.el (source)...done
Loading gnus...done
Loading pc-select...done
Loading paren...done
Starting Emacs daemon.
When done with this frame, type C-x 5 0
Making completion list... [3 times]

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Monnier]

severity 2520 wishlist
thanks

> 1) emacs -Q. Emacs process starts.
> 2) pkill -s 1 emacs. Emacs process dies.

> The more appropriate behavior would be to reload the configuration
> without restarting (i.e. reread X resource values).  This behavior
> would be especially useful for the daemon mode.

It could make sense, indeed.  It can be pretty problematic as well,
since most config files read by Emacs (i.e. site-start.el, default.el,
.emacs) are normally only read a single time per session, and in
a particular order, at a particular time, so rereading them later on can
very easily give you unexpected results.

It is a good practice to keep your .emacs file "idempotent", but I think
such files are the exceptions rather than the rule.  So, yes, it could
be handy, but it would have to come with big warnings "may not do what
you expect".

> I'm pretty sure previous snapshot versions used to work that way.

Maybe in some other world.


        Stefan

Processed: Re: bug#2520: 23.0.91; Dies on SIGHUP

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 2520 wishlist
bug#2520: 23.0.91; Dies on SIGHUP
Severity set to `wishlist' from `wishlist'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#2520: 23.0.91; Dies on SIGHUP

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 1) emacs -Q. Emacs process starts.
>> 2) pkill -s 1 emacs. Emacs process dies.
>
>> The more appropriate behavior would be to reload the configuration
>> without restarting (i.e. reread X resource values).  This behavior
>> would be especially useful for the daemon mode.
>
> It could make sense, indeed.  It can be pretty problematic as well,
> since most config files read by Emacs (i.e. site-start.el, default.el,
> .emacs) are normally only read a single time per session, and in
> a particular order, at a particular time, so rereading them later on can
> very easily give you unexpected results.
>
> It is a good practice to keep your .emacs file "idempotent", but I think
> such files are the exceptions rather than the rule.  So, yes, it could
> be handy, but it would have to come with big warnings "may not do what
> you expect".

So the suggestion here is to make Emacs re-read ~/.emacs on SIGHUP.  I
think that sounds like a useful feature -- it would allow you to, for
instance, ssh in to a machine, put (server-start) in ~/.emacs, and then
SIGHUP the Emacs process you want to talk to.

It's definitely something I could have used a number of times...  and
re-reading init files on SIGHUP isn't an unusual thing to do.

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

bug#2520: 23.0.91; Dies on SIGHUP

[Andreas Schwab]

On Sep 29 2019, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> It's definitely something I could have used a number of times...  and
> re-reading init files on SIGHUP isn't an unusual thing to do.

But only for demons.  Normally a process receives SIGHUP if its
controlling terminal goes away.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#2520: 23.0.91; Dies on SIGHUP

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Sep 29 2019, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> It's definitely something I could have used a number of times...  and
>> re-reading init files on SIGHUP isn't an unusual thing to do.
>
> But only for demons.  Normally a process receives SIGHUP if its
> controlling terminal goes away.

Yeah, that's true.

I guess SIGUSR1 and 2 are also taken...

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

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Sep 29 2019, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>
>>> It's definitely something I could have used a number of times...  and
>>> re-reading init files on SIGHUP isn't an unusual thing to do.
>>
>> But only for demons.  Normally a process receives SIGHUP if its
>> controlling terminal goes away.
>
> Yeah, that's true.
>
> I guess SIGUSR1 and 2 are also taken...

So do we actually want to do anything here?  Simply re-reading the
configuration comes with its own set of complications for us.

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas [2021-10-22 02:19:21] wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> On Sep 29 2019, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>>> It's definitely something I could have used a number of times...  and
>>>> re-reading init files on SIGHUP isn't an unusual thing to do.
>>> But only for demons.  Normally a process receives SIGHUP if its
>>> controlling terminal goes away.
>> Yeah, that's true.
>> I guess SIGUSR1 and 2 are also taken...

Not really: they're turned into input events and one of them can be used
for `debug-on-event` but the other is free.

> So do we actually want to do anything here?  Simply re-reading the
> configuration comes with its own set of complications for us.

BTW, if someone wants to re-read their init file upon SIGUSR1, they can
do so via something like:

    (define-key special-event-map [sigusr1] <...>)


-- Stefan

bug#2520: 23.0.91; Dies on SIGHUP

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I guess SIGUSR1 and 2 are also taken...
>
> Not really: they're turned into input events and one of them can be used
> for `debug-on-event` but the other is free.
>
>> So do we actually want to do anything here?  Simply re-reading the
>> configuration comes with its own set of complications for us.
>
> BTW, if someone wants to re-read their init file upon SIGUSR1, they can
> do so via something like:
>
>     (define-key special-event-map [sigusr1] <...>)

But should Emacs offer something along these lines by default?  I think
it makes some sense to do so, because people only think about adding
this after the first time they need it.  (Well, after the third time,
because we're too lazy to do it the first couple times around, and just
swear a lot instead.)

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

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-10-22 16:05:44] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I guess SIGUSR1 and 2 are also taken...
>>
>> Not really: they're turned into input events and one of them can be used
>> for `debug-on-event` but the other is free.
>>
>>> So do we actually want to do anything here?  Simply re-reading the
>>> configuration comes with its own set of complications for us.
>>
>> BTW, if someone wants to re-read their init file upon SIGUSR1, they can
>> do so via something like:
>>
>>     (define-key special-event-map [sigusr1] <...>)
>
> But should Emacs offer something along these lines by default?  I think
> it makes some sense to do so, because people only think about adding
> this after the first time they need it.  (Well, after the third time,
> because we're too lazy to do it the first couple times around, and just
> swear a lot instead.)

Do we have a `M-x <something>` to re-read the init file?
If not, why would it more important to offer a way to do it via SIGUSR?


        Stefan

bug#2520: 23.0.91; Dies on SIGHUP

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Do we have a `M-x <something>` to re-read the init file?
> If not, why would it more important to offer a way to do it via SIGUSR?

The use case is that you're ssh-ing in to an Emacs running on a machine,
and you want to communicate with that Emacs (because it has all the
information you absolutely need right now in *scratch*), but you haven't
set up emacs-server on it yet.  (Any similarity to something that's
happened to me a dozen times is purely coincidental.) 

So if you could put (server-start) in ~/.emacs and send it SIGUSR,
that'd be nice.

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

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-10-22 17:06:09] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Do we have a `M-x <something>` to re-read the init file?
>> If not, why would it more important to offer a way to do it via SIGUSR?
> The use case is that you're ssh-ing in to an Emacs running on a machine,
> and you want to communicate with that Emacs (because it has all the
> information you absolutely need right now in *scratch*), but you haven't
> set up emacs-server on it yet.  (Any similarity to something that's
> happened to me a dozen times is purely coincidental.) 
> So if you could put (server-start) in ~/.emacs and send it SIGUSR,
> that'd be nice.

So maybe rather than load the init file, we wan to use SIGUSR1 cause
Emacs to read ~/.emacs.d/sigusr1.el ?


        Stefan


PS: FWIW, when this happens, I use gdb to attach to the process
    and "call (intern ("server-mode"));" from there.
[ This said, it doesn't happen often, because I do enable `server-mode`
  in my init file.  ]

bug#2520: 23.0.91; Dies on SIGHUP

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So maybe rather than load the init file, we wan to use SIGUSR1 cause
> Emacs to read ~/.emacs.d/sigusr1.el ?

Sure, that would also make sense.  "Re-reading the startup file" sounds
like a less hacky interface, though.  

> PS: FWIW, when this happens, I use gdb to attach to the process
>     and "call (intern ("server-mode"));" from there.

Heh.  Hadn't thought about that.

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

bug#2520: 23.0.91; Dies on SIGHUP

[Stefan Kangas]

retitle 2520 Read configuration file on SIGUSR1
tags 2520 confirmed
thanks

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> So maybe rather than load the init file, we wan to use SIGUSR1 cause
>> Emacs to read ~/.emacs.d/sigusr1.el ?
>
> Sure, that would also make sense.  "Re-reading the startup file" sounds
> like a less hacky interface, though.
>
>> PS: FWIW, when this happens, I use gdb to attach to the process
>>     and "call (intern ("server-mode"));" from there.
>
> Heh.  Hadn't thought about that.

Retitling and adding the confirmed tag so this is easier to find.