git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Oct 27, 2015, 18:41 UTC
Message-ID
<20151027184151.GA12717@sigill.intra.peff.net>
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:
Show 7 quoted lines
> 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.

Show 11 quoted lines
> > 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
Previous: Noam PostavskyNext: Junio C Hamano
Message 10 of 29 in “git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?”
  1. Noam PostavskyOct 10, 2015
  2. Noam PostavskyOct 18, 2015
  3. Junio C HamanoOct 18, 2015
  4. Noam PostavskyOct 19, 2015
  5. Noam PostavskyOct 21, 2015
  6. Noam PostavskyOct 24, 2015
  7. Junio C HamanoOct 25, 2015
  8. Jeff KingOct 26, 2015
  9. Noam PostavskyOct 27, 2015
  10. Jeff KingOct 27, 2015
  11. Junio C HamanoOct 27, 2015
  12. Junio C HamanoOct 27, 2015
  13. Jeff KingOct 27, 2015
  14. Noam PostavskyOct 28, 2015
  15. Jeff KingOct 30, 2015
  16. Noam PostavskyOct 30, 2015
  17. Jeff KingOct 30, 2015
  18. Noam PostavskyOct 30, 2015
  19. Jeff KingOct 30, 2015
  20. Noam PostavskyNov 9, 2015
  21. Jeff KingNov 9, 2015
  22. Noam PostavskyNov 10, 2015
  23. Jeff KingNov 10, 2015
  24. Jeff KingNov 10, 2015
  25. Noam PostavskyNov 11, 2015
  26. Junio C HamanoDec 4, 2015
  27. Jeff KingDec 4, 2015
  28. Junio C HamanoDec 4, 2015
  29. Jeff KingDec 4, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.