From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1061 Path: news.gmane.org!not-for-mail From: orc Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Vision for new platform Date: Mon, 11 Jun 2012 01:53:49 +0800 Message-ID: <20120611015349.701fa061@sibserver.ru> References: <20120518010620.GW163@brightrain.aerifal.cx> <20120609192756.6e72f25e@sibserver.ru> <20120609074426.496a5e13@newbook> <20120609212411.GA163@brightrain.aerifal.cx> <87lijwnmao.fsf@gmail.com> <20120610132246.GF163@brightrain.aerifal.cx> <20120610225226.137363d0@sibserver.ru> <20120610151311.GH163@brightrain.aerifal.cx> <20120610235125.31f38cd7@sibserver.ru> <20120610163359.GJ163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1339350949 21205 80.91.229.3 (10 Jun 2012 17:55:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 10 Jun 2012 17:55:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1062-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 10 19:55: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 1SdmMX-0006n1-UZ for gllmg-musl@plane.gmane.org; Sun, 10 Jun 2012 19:55:42 +0200 Original-Received: (qmail 9324 invoked by uid 550); 10 Jun 2012 17:55:42 -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 9302 invoked from network); 10 Jun 2012 17:55:37 -0000 In-Reply-To: <20120610163359.GJ163@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:1061 Archived-At: On Sun, 10 Jun 2012 12:33:59 -0400 Rich Felker wrote: > On Sun, Jun 10, 2012 at 11:51:25PM +0800, orc wrote: > > > I don't think you're getting the issue at hand. Suppose you want > > > to be able to automatically bring down a particular daemon -- > > > perhaps to restart it with completely new configuration or to > > > switch to a new version of it. This could happen as part of an > > > automated upgrade process or under manual admin control. > > > > 'Automated' often becomes the source of problems, if this automated > > subsystem is not engineered properly. If we want daemon that will be > > responsible for other's daemons status and it will start and stop > > them automatically based on the admin's decision than it must be > > well-engineered and tested in many types of situations first. > > Without "automated", how do you intend for non-technical users to > upgrade important system components when their old version has a > critical vulnerability? Even if the system has a technically qualified > admin, nobody wants to go manually upgrading/restarting daemons on > tens, hundreds, or thousands of boxes... Okay, this will be sufficient for end users. > At least with pid files, you know the pid you kill _at one time_ > belonged to the daemon you wanted to kill. With pkill, you'll pick up > completely independent instances of the same program binary. Aw. Missed this important about pkill/killall. Thanks, my fault. * me really said some stupid things there. > 1. On a hobbyist or fully self-maintained system where you're willing > to manually do all the work of upgrading/restarting things, or on > certain embedded systems where reboot-on-upgrade is acceptable or > where you're sure you won't need security updates (because the system > does not interact with potentially-dangerous inputs), just start all > the daemons from your init script with no management and be done with > it. Components should not be designed in ways that _preclude_ this > ultra-simple setup. > > 2. On everything else, use your choice of robust daemon management > tool that starts daemons as direct children and therefore can observe > their death and/or intentionally kill them without any race > conditions. But with pushing something new we should really understand that it will not become a second 'systemd'. Thank you very much for explanation.