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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
