OK, first, thanks to those that helped out!!
I wasn't trapping the SIGHUP (thanks isotope!) that was killing the program because I wasn't running as a daemon - fixed that. I wasn't testing as a daemon because I was really testing other functionality in the program - all this tcp/signal/reboot stuff just came up as a side note, and I didn't think of the fg/bg issue and what signal I would actually get...
pg has a great point, that the peer should worry about closing the connection if he doesn't hear from me - the code is already working in a keep-alive (heartbeat?), non-blocking framework, so it wasn't to hard to add the close-connection on the other side. That was the real fix.
I am still going to do the clean-up outside the signal handler - I originally did some stuff like dumping my state and logging to a file inside the signal handler, and I saw intermittent SIGSEGV's when I was killing the program, which rang a bell about re-entrant syscall problems, as I mentioned. If the program doesn't have enough time to clean-up. so be it... It's all non-blocking anyway, and the poll timeout should be in the neighborhood of 0.2 secs, so I'm not too worried...
Thanks again trusty monks...
--In reply to Re: (slightly OT) catching SIGTERM when system goes down
by edan
in thread (slightly OT) catching SIGTERM when system goes down
by edan
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |