From: Jeff King <peff@peff.net>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?
Date: Tue, 27 Oct 2015 14:41:51 -0400 [thread overview]
Message-ID: <20151027184151.GA12717@sigill.intra.peff.net> (raw)
In-Reply-To: <CAM-tV--80xt_Ro_vQdgRmRxfy+2k2Ca13gVsjDHK+1pdsB_hqQ@mail.gmail.com>
On Mon, Oct 26, 2015 at 08:50:10PM -0400, Noam Postavsky wrote:
> On Mon, Oct 26, 2015 at 5:50 PM, Jeff King wrote:
> > But these days, people often have several simultaneous sessions open.
> > They may have multiple ssh sessions to a single machine, or they may
> > have a bunch of terminal windows open, each of which has a login shell
> > and will send HUP to its children when it exits.
>
> Yes, except that as far as I can tell the shell never sends HUP.
Ah, OK, I thought your original problem was too many HUPs. But reading
more, it is really "too many HUPs from Emacs".
I certainly do not get SIGHUPs when I close a terminal window. But I
would not be surprised if that behavior is dependent on shell version,
shell options, and terminal version.
> > I don't know what shell Noam is using, but I wonder if tweaking
> > that option (or a similar one if not bash) might be helpful to signal
> > "let this stuff keep running even after I exit".
>
> My normal login shell is zsh, but I've been testing with bash and I
> see the same behaviour with both. But the original reason for this
> whole thread is that when running from Emacs (not via shell), the
> daemon *always* get a SIGHUP as soon as "git push" finishes, which
> makes the caching thing not so useful. We do have a workaround for
> this by now though (start the daemon independently before calling "git
> push").
That makes sense. According to the emacs docs[1], "killing a buffer
sends a SIGHUP signal to all its associated processes". I don't know if
that is configurable or not, but even if it were, it might not do the
right thing (you probably _do_ want to send a signal to most processes,
just not the credential daemon).
Certainly the daemon could do more to "daemonize" itself. Besides
ignoring SIGHUP, it could detach from the controlling tty, close more
descriptors, etc. But along the lines that Junio mentioned, I'm not sure
if that's what people want. In general, it _is_ kind of associated with
your terminal session and should not live on past it.
I wonder if it would work in your case to simply nohup the credential
helper. I.e., put this in your git config:
[credential]
helper = "!nohup git credential-cache"
There are probably some weird things with how nohup works, though (e.g.,
it redirects stderr to stdout, which is not what you want). Ignored
signals are inherited by children, so you could probably just do:
[credential]
helper = "!trap '' HUP; git credential-cache"
That _almost_ works. Unfortunately, credential-cache installs its own
SIGHUP handler to clean up its socket. So it cleans up the socket, and
then chains to the original handler, which was to ignore the signal.
Meaning we keep running, but nobody can contact us. Whoops.
So I dunno. I think it would be reasonable to provide a config option to
tell the cache-daemon to just ignore SIGHUP (or alternatively, a general
option to try harder to dissociate itself from the caller). But I'm not
sure I'd agree with making it the default. I'd want to know if anybody
is actually _using_ the SIGHUP-exits-daemon feature. Clearly neither of
us is, but I wouldn't be surprised if other setups are.
-Peff
[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Signals-to-Processes.html
next prev parent reply other threads:[~2015-10-27 18:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-10 16:45 git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead? Noam Postavsky
2015-10-18 15:15 ` Noam Postavsky
2015-10-18 17:58 ` Junio C Hamano
2015-10-19 0:51 ` Noam Postavsky
2015-10-21 2:35 ` Noam Postavsky
2015-10-24 21:47 ` Noam Postavsky
2015-10-25 16:58 ` Junio C Hamano
2015-10-26 21:50 ` Jeff King
2015-10-27 0:50 ` Noam Postavsky
2015-10-27 18:41 ` Jeff King [this message]
2015-10-27 19:04 ` Junio C Hamano
2015-10-27 17:52 ` Junio C Hamano
2015-10-27 18:47 ` Jeff King
2015-10-28 3:46 ` Noam Postavsky
2015-10-30 0:10 ` Jeff King
2015-10-30 0:43 ` Noam Postavsky
2015-10-30 0:50 ` Jeff King
2015-10-30 1:20 ` Noam Postavsky
2015-10-30 21:08 ` Jeff King
2015-11-09 2:58 ` Noam Postavsky
2015-11-09 15:53 ` Jeff King
2015-11-10 1:05 ` Noam Postavsky
2015-11-10 12:25 ` Jeff King
2015-11-10 12:26 ` Jeff King
2015-11-11 0:22 ` Noam Postavsky
2015-12-04 18:55 ` Junio C Hamano
2015-12-04 19:06 ` Jeff King
2015-12-04 20:05 ` Junio C Hamano
2015-12-04 23:25 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151027184151.GA12717@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).