Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]