Init : someone could comment this ?

[Enrico Scholz]

Nils Philippsen <nphilipp at redhat.com> writes:

>> 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

uups, I meant 'initng'.


>> 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.

I think, when somebody wants to run a server, he has to understand how
it works and how to configure it.  When admin can not figure out correct
cmdline options, how can he configure the server in a secure manner?


>> > 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().

There is absolutely no problem with fork()/exec(); performance depends on
the program being executed.  E.g. 'fnord' HTTP server which is started
(fork(2) + execve(2)) by tcpserver (an inetd like program) for every new
request is faster than apache httpd with no-pipelined requests.

When '... do something ...' is

| if test ! -e /etc/ssh/ssh_host_key/...'; then ... expensive tasks ...; fi

there will be "only" the overhead of /one/ execve("/bin/sh", ...)
('test' is a bash builtin) compared to the plain 'execve("<daemon>",
...)'.  The number of fork()'s stays constant.


The real overhead is in loading '/bin/sh' and in interpreting the script.


>> > 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

then, the program is broken...


>> | /usr/bin/setuidgid postgres /usr/bin/postmaster -D /var/lib/pgsql/data
>
> This only works because you assume some things as a given.

And these things *are* given.  Current postgresql's initscript is
complicated because it contains code being executed exactly once.
Speaking in initng terms, you could write


--- daemons/postgresql ----
use    = scripts/postgresql-prepare   # depend on it only, when activated
daemon = postmaster -D ...

--- scripts/postgresql-prepare
exec   = /usr/libexec/postgresql-prepare

--- /usr/lib/postgresql/postgresql-prepare ---
#! /bin/sh
...
initng-chkconfig scripts/postgresql-prepare off



This means, the expensive (has to spawn /bin/sh) -prepare script turns
off itself after running once.



> 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).

Question is where to draw the line. E.g. do you make 'rpm -V postgresql'
to verify that program is not corrupted?


>> >> 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

Resulting scripts will be much longer.  E.g. how much lines of python
code are required for

| sed '/^foo/s!/bin!/opt!' file | tac

?

Most time in preparation code will be spent in "payload" (e.g. ssh-keygen).


> 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.

Usually, preparation code will be executed only once.  And I do not care
about whether first startup needs 40 or 20 seconds. But I care about,
whether regular startup needs 20 or 15 seconds.

And there *is* the bloat of initializing the python runtime environment
which can make this difference.


>> 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.

What are you missing specifically?



Enrico