From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1045 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Vision for new platform Date: Sat, 9 Jun 2012 17:24:11 -0400 Message-ID: <20120609212411.GA163@brightrain.aerifal.cx> References: <20120518010620.GW163@brightrain.aerifal.cx> <20120609192756.6e72f25e@sibserver.ru> <20120609074426.496a5e13@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339277329 720 80.91.229.3 (9 Jun 2012 21:28:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jun 2012 21:28:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1046-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 09 23:28:48 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SdTDA-0001Tm-HH for gllmg-musl@plane.gmane.org; Sat, 09 Jun 2012 23:28:44 +0200 Original-Received: (qmail 5175 invoked by uid 550); 9 Jun 2012 21:28:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5166 invoked from network); 9 Jun 2012 21:28:44 -0000 Content-Disposition: inline In-Reply-To: <20120609074426.496a5e13@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1045 Archived-At: 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