Nils Philippsen <nphilipp(a)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