[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120611015349.701fa061@sibserver.ru>
Date: Mon, 11 Jun 2012 01:53:49 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
On Sun, 10 Jun 2012 12:33:59 -0400
Rich Felker <dalias@...ifal.cx> 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.
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.
