From: Wouter van Kleunen <kleunen@cs.utwente.nl>
To: "leon j. breedt" <ljb@neverborn.ORG>
Cc: <gentoo-dev@gentoo.org>
Subject: Re: [gentoo-dev] Init replacement
Date: Sat, 3 May 2003 11:08:55 +0200 (MEST) [thread overview]
Message-ID: <Pine.SOL.4.33.0305031058340.2984-100000@taurus> (raw)
In-Reply-To: <000901c310f5$3c1d7020$4b00a8c0@valhalla>
On Sat, 3 May 2003, leon j. breedt wrote:
> 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.
this is definitly a good option, i'll definitly add this
> 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.
Yes, that is already in there
> 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.
Yup, that is also supported.
> 4. deep dependency checking when determining what to start up/stop.
> and when restarting,
> only start up dependant things which were running when stopped.
>
Yes. Well, for the moment, you can only stop services that do not have
dependent services running. I plan to make that stronger
> 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.
That is definitly possible. sysvinit uses a fifo to communicate. I could
write an IO part in pinit that could handle these commands. But i could
also write a pinit alternative.
>
> 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.
>
Yes. I have thought of adding a script-service. But i removed it, because
i do not like scripts. I agree that they are convenient for executing a
collection of commands, but bash is a very weak programming language.
I will think about adding scripts. Maybe just to lower the difference
between my init and sysvinit. But rather not bash, bash is ugly :-(
it would be nice if people wrote more scripts using functional languages.
(haskell, miranda, etc...)
> i'm extremely interested in development of this, don't stop development
> :)
>
> regards,
> leon.
>
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-05-03 9:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-02 9:34 [gentoo-dev] Init replacement Wouter van Kleunen
2003-05-02 9:44 ` Paul de Vrieze
2003-05-02 9:54 ` Wouter van Kleunen
2003-05-02 10:50 ` Terje Kvernes
2003-05-02 11:24 ` Wouter van Kleunen
2003-05-02 13:57 ` Terje Kvernes
2003-05-02 16:35 ` Wouter van Kleunen
2003-05-02 17:08 ` Jon Kent
2003-05-02 17:20 ` Paul de Vrieze
2003-05-02 19:23 ` Wouter van Kleunen
2003-05-02 19:54 ` Evan Powers
2003-05-02 20:03 ` Wouter van Kleunen
2003-05-02 19:56 ` Paul de Vrieze
2003-05-02 20:09 ` Sven Vermeulen
2003-05-02 12:01 ` Jim Bowlin
2003-05-02 21:53 ` leon j. breedt
2003-05-03 9:08 ` Wouter van Kleunen [this message]
2003-05-03 10:05 ` Martin Schlemmer
2003-05-04 16:05 ` Wesley Leggette
2003-05-04 18:12 ` Martin Schlemmer
2003-05-04 23:48 ` Wesley Leggette
2003-05-05 12:33 ` foser
2003-05-05 18:31 ` Wesley Leggette
2003-05-03 13:20 ` leon j. breedt
2003-05-04 9:42 ` Paul de Vrieze
2003-05-04 12:39 ` [gentoo-dev] " Robert Wittams
2003-05-05 10:20 ` A.Waschbuesch
-- strict thread matches above, loose matches on Subject: below --
2003-05-02 20:34 [gentoo-dev] " Joshua Brindle
2003-05-02 21:36 ` Martin Schlemmer
2003-05-02 21:50 ` George Shapovalov
2003-05-03 9:14 ` Wouter van Kleunen
2003-05-04 16:02 ` Wesley Leggette
2003-05-05 5:23 ` C. Brewer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.SOL.4.33.0305031058340.2984-100000@taurus \
--to=kleunen@cs.utwente.nl \
--cc=gentoo-dev@gentoo.org \
--cc=ljb@neverborn.ORG \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox