Re: pidsig 0.11 - a fghack like de-daemonisation tool

[Janos Farkas <chexum@gmail.com>]

On Wed, Jun 2, 2010 at 19:46, Laurent Bercot
<ska-supervision@skarnet.org> wrote:
> [kind words]

Thanks!

>  I would advise to implement just the features you need. Such a tool,
> like fghack, is very handy to have when there's no other choice; however,
> we don't want people to rely on them, to use them as excuses for bad
> coding practices. And if you make pidsig too powerful, you *know* it's
> going to happen.

In principle, I agree - it does what I originally wanted, I have some
corner cases in mind that can be difficult to tackle (what if pidsig
itself crashes, but the daemon below it doesn't - shall it try to do
something with the pid file?).

These kinds of problems are not that theoretical - just recently I saw
svscan/svscanboot crashing on a >1y uptime box, taking many of the
processes with it, including most of the supervise infrastructure,
very likely not due to any fault in them - could be oom gone wild,
cosmic rays hitting svscan memory, whatever).

The host stayed up and admin access was possible (thanks mainly to
sshd being a long running daemon), but the state the processes was
left in was nothing to be glad about.

Another question would be if there are more ways to reliably connect
to any given process detecting it being gone - but all the current
daemons that I run can be handled now :)

>  Working in professional environments has made me very disillusioned
> about the way people design software (when they design it) and understand
> Unix (when they understand it). Having workarounds is good, but if you
> make it too easy for people to misbehave, *they will*.
>
>  So... scratch your itch, but don't go out of your way to accommodate
> all kinds of ugly practices. :)

I hear you, points taken :)  Please return to your regularly scheduled
supervision :)

Janos