Date: Sat, 9 Jun 2012 17:24:11 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Vision for new platform On Sat, Jun 09, 2012 at 07:44:26AM -0700, Isaac Dunham wrote: > > > pid files > > Yup, when daemon dead (or someone cut off power), there is nothing to > > kill > > > killall > > Horrible and harmful > > Maybe pgrep/pkill sucks less and will replace that horrible approach > > to store pidfiles and believe that daemon is still running. > > Actually systemd is more, MORE harmful than this old stuff. > IIRC, pkill is racey--it checks the PID for a name, then kills the PID > (meaning that if you have almost all the processes supported running, Almost all traditional uses of PIDs are racy and outright WRONG. Unless you take extreme care, the *only* processes to which a PID value is meaningful are the process itself and its parent process. The parent process controls the lifetime of a PID; for the purposes of robust resource management, child process PIDs should be treated similarly to pointer's in the parent's address space: not something you share with the outside world. With that said, there are some legitimate ways to use PIDs elsewhere. For instance if you have a process that never exits or crashes (i.e. a proper robust daemon), then the only way the PID can be invalidated is by explicitly terminating it, and assuming you only have one admin or perform some sort of human-space synchronization with other admins before killing anything, all is well and you can use the PID to kill the process or send other signals (e.g. for reloading config). There are also ways to mediate use of the PID through the parent process, but these depend on the parent process being robust and not exiting unexpectedly. Where systemd is right is in deprecating pidfiles and other legacy means of starting and stopping daemons based on searching the process table. Where it's wrong is in putting all of this logic in pid #1 (init). A much better approach for systems that need automatic stopping and starting of daemons would be to have a tiny daemon-supervisor process to handle it; small systems with a very "hands-on" admin not wanting to automate this could then skip the supervisor daemon and start/stop manually. Another approach would be for daemons to open unix sockets to control their termination. The existence of the socket would reflect whether the daemon is running, and serve as a race-free way to terminate the current instance. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.