From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev-return-2871-arch-gentoo-dev=gentoo.org@gentoo.org>
Received: (qmail 19990 invoked by uid 1002); 2 May 2003 21:53:18 -0000
Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:gentoo-dev@gentoo.org>
List-Help: <mailto:gentoo-dev-help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@gentoo.org
Received: (qmail 14694 invoked from network); 2 May 2003 21:53:18 -0000
From: "leon j. breedt" <ljb@neverborn.ORG>
To: "'Wouter van Kleunen'" <kleunen@cs.utwente.nl>
Cc: <gentoo-dev@gentoo.org>
Date: Sat, 3 May 2003 09:53:10 +1200
Message-ID: <000901c310f5$3c1d7020$4b00a8c0@valhalla>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2605
In-Reply-To: <Pine.SOL.4.33.0305021131070.3874-100000@taurus>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: Re: [gentoo-dev] Init replacement
X-Archives-Salt: 37f4154f-01e2-409e-9149-1ea1ac5de28b
X-Archives-Hash: 7030d80b8b35c7b949d753b77a79dcca

hi,

i as well looked into doing this, and came to the conclusion that the
following are desirable attributes for a replacement init:

    1. secure daemon startup (i.e. as different user, in chroot, etc).
basically,
       incorporating the functionality of start-stop-daemon into init.
    2. daemon monitoring/controlling at an init level. i.e. you have a
guaranteed
       working way of checking service status, sending signals, etc.
very useful
       would be the ability to execute configurable commands/scripts on
status
       change. basically, incorporating similar functionality to djb's
daemontools.
    3. standardized, controllable output to TTY. i.e. be able to
suppress anything
       that a daemon/service tries to output, but log it somewhere. it
should be
       possible to flag something that could be interactive though, like
fsck.
       abstracting this would make it trivial to support different
startup displays,
       like a progress bar, or graphical/icon based startup.
    4. deep dependency checking when determining what to start up/stop.
and when restarting,
       only start up dependant things which were running when stopped.

it seems like you've thought of most of these cases. don't throw away
the wisdom
incorporated in sysvinit though. i'd recommend trying to make your init
have the same
semantics from an external point of view where possible so that
userspace utilities
such as wall, shutdown, etc, keep on working.

i'm not entirely sure i'd want to use XML for everything though. i think
a nice
approach would be to put the *metadata* about a service in XML, but the
actual
mechanics of starting/stopping the service in a seperate script. of this
script,
you expect things like that if it starts a daemon, its pid will be the
pid you get
when you exec it. have a well-defined interface you expect from the
scripts,
either return codes or text they output on success/failure, but scripts
are
very useful for executing a collection of commands. have the script
start with
#!/sbin/your-interpreter so that executing the script on its own still
executes
it in its managed environment.

i'm extremely interested in development of this, don't stop development
:)

regards,
leon.


--
gentoo-dev@gentoo.org mailing list