On Mon, 2008-01-07 at 13:11 +0100, Enrico Scholz wrote: > Nils Philippsen <nphilipp@xxxxxxxxxx> 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@xxxxxxxxxx "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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
