On Mon, 2008-01-07 at 17:05 +0100, Enrico Scholz wrote:
> Nils Philippsen <nphilipp@xxxxxxxxxx> writes:
> > 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?
Along that line, everybody should be able to run configure && make &&
make install and wrap their own packages, so why should we bother ;-)?
Seriously, I can cope with command line arguments and still like
sysconfig files that are more understandable than just plain
"OPTS='--foo -x=y -a'". I'm happy if I get things done without having to
read the documentation for the common case. I'm not saying admins
shouldn't be able to influence the cmd line options directly if they
wish.
> The real overhead is in loading '/bin/sh' and in interpreting the script.
Agreed, I got this wrong.
> >> > 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...
I don't think that there's a standard -- de-facto or written down -- that mandates this.
> > 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?
You know what I mean -- verifying the package integrity is just silly.
> Resulting scripts will be much longer. E.g. how much lines of python
> code are required for
>
> | sed '/^foo/s!/bin!/opt!' file | tac
>
> ?
Where would you find such a line in an init script? I could construe and
equally short line in python that would take much more to be implemented
in shell and tools. That proves nothing.
>
> 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.
The thing with the python runtime is that you'd only need to initialize
it once. Thanks to proper use of namespaces and exceptions one actually
can try to load other python modules into the same address space and not
make the whole process unstable. An empty python script takes between
10ms and 30ms start to finish on my machine here. If that initialization
time is taken only once, that's unlikely to be a bottleneck.
> >> 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?
Powerful string ops come to mind, built-in regular expressions or
exceptions. I can get by without, but once you're used to it ;-).
Note that I'm not necessarily favouring a python-based init tool, I'm
just not buying your arguments against it.
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
