| 1 |
hi, |
| 2 |
|
| 3 |
i as well looked into doing this, and came to the conclusion that the |
| 4 |
following are desirable attributes for a replacement init: |
| 5 |
|
| 6 |
1. secure daemon startup (i.e. as different user, in chroot, etc). |
| 7 |
basically, |
| 8 |
incorporating the functionality of start-stop-daemon into init. |
| 9 |
2. daemon monitoring/controlling at an init level. i.e. you have a |
| 10 |
guaranteed |
| 11 |
working way of checking service status, sending signals, etc. |
| 12 |
very useful |
| 13 |
would be the ability to execute configurable commands/scripts on |
| 14 |
status |
| 15 |
change. basically, incorporating similar functionality to djb's |
| 16 |
daemontools. |
| 17 |
3. standardized, controllable output to TTY. i.e. be able to |
| 18 |
suppress anything |
| 19 |
that a daemon/service tries to output, but log it somewhere. it |
| 20 |
should be |
| 21 |
possible to flag something that could be interactive though, like |
| 22 |
fsck. |
| 23 |
abstracting this would make it trivial to support different |
| 24 |
startup displays, |
| 25 |
like a progress bar, or graphical/icon based startup. |
| 26 |
4. deep dependency checking when determining what to start up/stop. |
| 27 |
and when restarting, |
| 28 |
only start up dependant things which were running when stopped. |
| 29 |
|
| 30 |
it seems like you've thought of most of these cases. don't throw away |
| 31 |
the wisdom |
| 32 |
incorporated in sysvinit though. i'd recommend trying to make your init |
| 33 |
have the same |
| 34 |
semantics from an external point of view where possible so that |
| 35 |
userspace utilities |
| 36 |
such as wall, shutdown, etc, keep on working. |
| 37 |
|
| 38 |
i'm not entirely sure i'd want to use XML for everything though. i think |
| 39 |
a nice |
| 40 |
approach would be to put the *metadata* about a service in XML, but the |
| 41 |
actual |
| 42 |
mechanics of starting/stopping the service in a seperate script. of this |
| 43 |
script, |
| 44 |
you expect things like that if it starts a daemon, its pid will be the |
| 45 |
pid you get |
| 46 |
when you exec it. have a well-defined interface you expect from the |
| 47 |
scripts, |
| 48 |
either return codes or text they output on success/failure, but scripts |
| 49 |
are |
| 50 |
very useful for executing a collection of commands. have the script |
| 51 |
start with |
| 52 |
#!/sbin/your-interpreter so that executing the script on its own still |
| 53 |
executes |
| 54 |
it in its managed environment. |
| 55 |
|
| 56 |
i'm extremely interested in development of this, don't stop development |
| 57 |
:) |
| 58 |
|
| 59 |
regards, |
| 60 |
leon. |
| 61 |
|
| 62 |
|
| 63 |
-- |
| 64 |
gentoo-dev@g.o mailing list |
Archives