GNU bug report logs -
#21866
How to stop children of pty subprocesses from receiving a SIGHUP when main subprocess exits?
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
While investigating a magit bug[1], we found that when a subprocess
with process-connection-type = pty ends, any subprocesses it has
spawned will receive a SIGHUP.
A simple way to see the problem is doing
git config --global credential.help='cache --timeout=3600'
And then doing a "git push" to a password protected https remote twice
from M-x eshell. You will be asked for your password both times. The
same from M-x shell only asks the first time (note that after a
successful push from a normal shell, you won't be asked for a password
in eshell either because it can pick up existing daemons, it's just
that it always kills its own daemons).
For a self contained example, using the attached files:
emacs -Q -l start-process-note-sighup.el
And notice that sighup.log contains "got sigup". Doing the same in
bash, a sighup is not sent if job control is on (the default for
interactive shells).
xterm -e 'bash -c "set -m ; ./call-note-sighup"' ; cat sighup.log #
no sigup, do pkill note-sighup after
xterm -e 'bash -c "set +m ; ./call-note-sighup"' ; cat sighup.log # sigup sent
We have a workaround for the git daemon situation, and I'm also
looking into possibly adding an option to git to ignore the sighup[2],
but I think it would make sense for Emacs to be able to avoid sending
sighup in this situation too. I poked around process.c a bit, but I
couldn't figure out where this signal gets sent from.
[1]: https://github.com/magit/magit/issues/2309
[2]: http://www.mail-archive.com/git%40vger.kernel.org/msg79211.html
This bug report was last modified 7 years and 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.