public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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


  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