Nils Philippsen <nphilipp@xxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
