[ojn]

Good writeup, and lots of detail.

But my immediate conclusion isn't "Signals are dangerous and let's go deep on the complexity thereof". Instead, my primary conclusion really is "Someone forgot to write a testcase to make sure log rotation behavior is covered, so of course it might regress".

[brian_cloutier]

Both are true.

I would throw in a third conclusion: given that you're directly using signals (without a wrapper to rationalize the interface) your team should be composed of people who fully understand how signals work. Neither the person who wrote this code or the person who reviewed it had internalized the fact that "the default SIGHUP handler kills the process", and therefore using signals was an inappropriate decision for this team.

But this is an exceptionally high bar; most interfaces do not require that your devs have memorized so many details. Signals expose a terrible interface and there is essentially no satisfying way to make use of them. We should expect better from the tools we use.

[ok_dad]

I dunno, I don't even program in C and when scrolling through the diff I immediately said to myself, "Hey, I bet that callback registration they removed for SIGHUP could be an issue; I would have no-op'ed the callback and left it in there." Of course, I had the privilege of knowing that there was something wrong with that specific code diff relating to signals.

My take is similar to yours: only use tech and features the plurality your team understands. If the people leave that are the only ones who understand the fancy stuff, then you run into this type of issue. At my current job, the guy who setup the database put all kinds of fancy extensions, triggers, and procedures in there and no one knows how to dissect it or what it all does, so now we're running old versions of code in a database container. I am sure someday it will be my job to replace that black box with something else, and probably just move the data from one to the other with ETL methods.