Post by Nils PhilippsenPost by Enrico ScholzI 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'.
Post by Nils PhilippsenPost by Enrico Scholzoptions 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?
Post by Nils PhilippsenPost by Enrico Scholztrivially to be solved by executing helper scripts instead of the daemon
itself
| #!/bin/sh
| ... do something ...
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.
Post by Nils PhilippsenPost by Enrico ScholzPost by Nils Philippsenand 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...
Post by Nils PhilippsenPost by Enrico Scholz| /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.
Post by Nils PhilippsenTo 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?
Post by Nils PhilippsenPost by Enrico ScholzPost by Nils PhilippsenPost by Enrico ScholzBut 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).
Post by Nils Philippsenbeyond 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.
Post by Nils PhilippsenPost by Enrico ScholzPerhaps 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