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. > This is all further complicated by bash's huponexit option, which I > think is off by default. So I, for example, have never noticed this > behavior even with multiple xterms, because my cache never actually gets > SIGHUP. Interesting, I was not aware of this option. I tried enabling it, but I see no difference, the daemon still receives no SIGHUP. Could it be a bug in my version of bash? GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu) Ah, it seems I'm not the only one: (Raphael Ahrens at http://unix.stackexchange.com/a/85296/47926) Bash seems to send the SIGHUP only if it self received a SIGHUP[...] So if you type exit or press Ctrl+D all background process will remain, since this does not send a hang up signal to the Bash. [...] There is an option to send the SIGHUP on exit, but it does not work on my Bash 4.2.25. Maybe it works for you > 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"). -- 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
