From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 14694 invoked from network); 2 May 2003 21:53:18 -0000 From: "leon j. breedt" To: "'Wouter van Kleunen'" Cc: 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: 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