Init : someone could comment this ?

[Nils Philippsen]

On Mon, 2008-01-07 at 13:11 +0100, Enrico Scholz wrote:
> Nils Philippsen <nphilipp at redhat.com> writes:
> 
> >> I think, nobody doubts that current initsystem is the worst one of
> >> the major linux distributions.
> >
> > Can the hyperbole please -- we know what we have otherwise we wouldn't
> > be having this discussion.
> 
> I can not remember how long there are discussions about replacing
> RH's initsystem (perhaps 5-6 years), and nothing happened.  Other
> distributions implemented more (upstart, syslog-ng) or less (suse,

Is syslog-ng really an init system (if yes, it would have a mighty
confusing name)?

> mandriva) innovative methods in the meantime.  And now, RH tries to
> write its own implementation by adding some d-bus features and using
> a bloaty scripting language around current initscripts?

Currently, there are no "innovative" init systems that can really be
called a standard. Therefore if the other available projects are found
lacking in some areas, trying to come up with something new that meets
the needs is an option that's perfectly fine with me. Mind that what
will get used (something existing or something new) is still in
discussion and not carved in stone yet, at least that's what I read from
FCNewInit[1].

[1]: http://fedoraproject.org/wiki/FCNewInit

> >> By changing paradigm from forking to non-forking daemon you can avoid
> >> all the complicated 'stop' code; e.g. 'start' will be
> >> 
> >> | pid = fork();
> >> | if (pid==0) { /* ... */ execve(...); }
> >> 
> >> and 'stop' be
> >> 
> >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL);
> >
> > That'd be all fine and dandy for daemons that simply need to be
> > started
> 
> how much resp. which daemons are not in this category?

If all prerequisites can be assumed as given, then none. I'm not
convinced that this assumption is a safe one to make.

> > without any variable options
> 
> options are trivially to solve; e.g. by an easy to parse one-option-per-line
> configuration file or by 'argv = --foo --bar' stylish options in the service
> description file.

Unless you specify that the command line options of the daemons are a
valid interface to have here, some logic to convert speaking
configuration options into command line options is needed. Read the
bzfs(6) manpage for an example with numerous, in part mutually exclusive
command line options where I'd rather give the user something else which
is easier to understand. 

> > or preparations
> 
> trivially to be solved by executing helper scripts instead of the daemon
> itself
> 
> | #!/bin/sh
> | ... do something ...
> | exec <daemon> "$@"

There goes the advantage of not having to fork()/exec().

> > and are obliging enough to write pid files.
> 
> pid files are an anachronism required for initsystems with forking
> daemons

There's no guarantee that the pid of the child process that the init
system forked will be the pid of the long running process whom you need
to send signals later on in order to end it. PID files are one way to
find this out halfway deterministically.

> > I don't think that e.g. the postgresql
> 
> works perfectly in this way; e.g. I start it with
> 
> | /usr/bin/setuidgid postgres /usr/bin/postmaster -D /var/lib/pgsql/data

This only works because you assume some things as a given. To make the
init process robust, services should check their prerequisites before
starting, or even ensure that they are met (e.g. /etc/init.d/sshd
generating host keys).

> >> But python or other bloaty scripting languages are not a solution and
> >> completely unacceptable at this place.
> >
> > "Bloaty" is something that could be solved, don't you think?
> 
> Not with python or perl.

I've shown you the numbers. Why you still insist on it being bloated
beyond redemption is a mystery to me. It's more powerful than shell, but
that's easy since shell in itself can't do much without resorting to
external executables with all the fork()/exec() overhead involved. Being
powerful is not the same as being bloated in my book.

>  Perhaps lua.  But I really do not see why an
> extra scripting language is required for the initsystem.  sh/bash is
> perfect for doing potential preparation tasks.

Shell being perfect for anything beyond the most simple things is an
opinion that I can't share, even if you avail yourself of using
bashisms.

> > bash takes up about 5.1MB.
> 
> you mean the 750kb sized 'bash' binary and the >4 MB documentation plus
> locale files?

Most of the modules contain their own documentation as well. Granted,
bash documentation is easier to strip away ;-). Anyway, my point was
that this would be small enough that bothering about the size of it
seems a waste of time.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011