[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
