On Thu, 24 Mar 2016 07:18:13 +0000 (UTC) mlel...@serpens.de (Michael van Elst) wrote:
> r...@marples.name (Roy Marples) writes: > > >See here: > >http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html > > ... handling crashing programs reliably > > isn't a worthwhile goal to me. I don't understand that line of thinking. Programs terminate abnormally all the time. It doesn't have to be a program crash. It could be signalled; it could be signalled by a sysadmin other than the one currently looking at the pidfile. The crash may also originate in a library. Libraries are increasingly developed on Linux where the default configuration supports overcommitted memory. Because malloc never fails, it's not unusual for it not to be tested, or for the error path to be broken. On NetBSD it will fail, of course, and down will come baby, cradle and all. Resources allocated by the OS -- memory, file descriptors, etc. -- are cleaned up automatically, whether or not exit(3) is called. If they weren't, would you still feel the same way? Pidfiles and tempfiles are examples of resources that are not allocated by the OS and are not cleaned up automatically. Stale pidfiles in particular are misleading to the point of dangerous insofar as they tempt the admin to kill the wrong process. No one considers that desirable. What I find baffling is saying it's OK. Why? Because worse is better? Because tradition? I reject the comparison to systemd. A tiny daemon to manage pidfiles is exactly what systemd is *not*. It does not bind together a bunch of different services. It does not require anything be rewritten. It does not require it even be used, if fallback to current behavior is supported. What it does do is fix a recognized problem in the most minimal way possible. --jkl
