GNU bug report logs - #2520
Read configuration file on SIGUSR1

Previous Next

To reply to this bug, email your comments to 2520 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: pent <pent <at> aparamon.msk.ru>
To: emacs-pretest-bug <at> gnu.org
Cc: rfrancoise <at> debian.org
Subject: 23.0.91; Dies on SIGHUP
Date: Sun, 01 Mar 2009 12:07:45 +0300

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]

Message #12 received at 2520 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: cmr.Pent <at> gmail.com
Cc: 2520 <at> debbugs.gnu.org, rfrancoise <at> debian.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 01 Mar 2009 17:50:05 -0500

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

Message #17 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rfrancoise <at> debian.org, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 29 Sep 2019 15:59:06 +0200

Stefan Monnier <monnier <at> 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

Message #20 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rfrancoise <at> debian.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 29 Sep 2019 16:19:10 +0200

On Sep 29 2019, Lars Ingebrigtsen <larsi <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #23 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: rfrancoise <at> debian.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 29 Sep 2019 17:15:17 +0200

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

> On Sep 29 2019, Lars Ingebrigtsen <larsi <at> 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

Message #26 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rfrancoise <at> debian.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, cmr.Pent <at> gmail.com,
 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 02:19:21 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>> On Sep 29 2019, Lars Ingebrigtsen <larsi <at> 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.

Message #29 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: rfrancoise <at> debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Andreas Schwab <schwab <at> linux-m68k.org>, cmr.Pent <at> gmail.com,
 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 08:03:40 -0400

Stefan Kangas [2021-10-22 02:19:21] wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>>> On Sep 29 2019, Lars Ingebrigtsen <larsi <at> 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

Message #32 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, rfrancoise <at> debian.org,
 Stefan Kangas <stefan <at> marxist.se>, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 16:05:44 +0200

Stefan Monnier <monnier <at> 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

Message #35 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, rfrancoise <at> debian.org,
 Stefan Kangas <stefan <at> marxist.se>, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 10:59:30 -0400

Lars Ingebrigtsen [2021-10-22 16:05:44] wrote:
> Stefan Monnier <monnier <at> 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

Message #38 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, rfrancoise <at> debian.org,
 Stefan Kangas <stefan <at> marxist.se>, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 17:06:09 +0200

Stefan Monnier <monnier <at> 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

Message #41 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, rfrancoise <at> debian.org,
 Stefan Kangas <stefan <at> marxist.se>, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Fri, 22 Oct 2021 18:31:05 -0400

Lars Ingebrigtsen [2021-10-22 17:06:09] wrote:
> Stefan Monnier <monnier <at> 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.  ]

Message #44 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, rfrancoise <at> debian.org,
 Stefan Kangas <stefan <at> marxist.se>, cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 24 Oct 2021 14:20:06 +0200

Stefan Monnier <monnier <at> 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

Message #47 received at 2520 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rfrancoise <at> debian.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 cmr.Pent <at> gmail.com, 2520 <at> debbugs.gnu.org
Subject: Re: bug#2520: 23.0.91; Dies on SIGHUP
Date: Sun, 24 Oct 2021 15:08:38 -0700

retitle 2520 Read configuration file on SIGUSR1
tags 2520 confirmed
thanks

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.