Conversation

Notices

1. Embed this notice
   feld (feld@friedcheese.us)'s status on Friday, 08-Nov-2024 03:00:25 JST feld

   • Shawn Webb
   • Jim Salter
   @lattera @jimsalter same, I've never seen this once in like ~20 years of being an avid FreeBSD user
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Friday, 08-Nov-2024 04:35:55 JST feld

     in reply to

     • Shawn Webb
     • Jim Salter
     @lattera @jimsalter It wouldn't even make sense to trap SIGINFO and exit or crash; if you're writing a tool primarily aimed at Linux you likely never even know SIGINFO exists and if the software doesn't recognize SIGINFO nothing should happen or any stray signal would cause the same problem.
     
     I *do* have a memory of some brain-damaged Linux tool that did crazy things with signals... *scratching head*... GNU dd requires you send SIGUSR1 to get statistics but that's not it. There's another piece of software I've run into in the last 10 years that did something absolutely crazy when it received a SIGHUP. I think it treated it like SIGTERM.
     
     I'd be willing to bet money this never happened and it was something else misbehaving with SIGHUP.
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Friday, 08-Nov-2024 04:37:08 JST feld

     in reply to

     • Shawn Webb
     • Jim Salter
     @jimsalter @lattera oh god I think I just remembered -- I think it's socat because I wrote an rc script for it for FreeBSD and I naively added a "reload" option and was shocked to see it kill the service
     
     from its man page:
     
     sighup, sigint, sigquit
     Has socat pass signals of this type to the sub process. If no address has this
     option, socat terminates on these signals.