systemd: Is it wrong?

[Matthew Garrett]

On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote:
> Once upon a time, Matthew Garrett <mjg59 at srcf.ucam.org> said:
> > The suggestion isn't that having the options is wrong
> 
> Well, that's what you said before (conveniently snipped from your
> reply).  You compared CLI args/env vars to the BKL as something to be
> eliminated; specifically, you said (and I quoted):
> 
> > In this case there are sound
> > technical arguments against configuration by command line argument or
> > environment variable
> 
> You have still failed to enumerate even one of the "sound technical
> arguments".

"Configuration by", not overriding configuration. It's a mistake to have 
your daemon's configuration be handled by a shell script that's sourced 
into existing environment. It's reasonable for an admin to override 
configuration on an as-needed basis.

> > it's that having 
> > them as the primary means of configuration is poor design. If your 
> > entire configuration takes the form of a shell script that constructs a 
> > set of command line options then you've increased fragility for no 
> > benefit. Having a proper configuration file and allowing admins to 
> > override specific aspects of that from the command line isn't a problem.
> 
> You are moving the target (to a worst-case example) and still not
> winning your argument.

The discussion was about having significant quantities of configuration 
in /etc/sysconf in the form of shell fragments.

> This is more than theoretical to me; a small package I maintain is one
> example of a command-line configured daemon.  The shmpps daemon is a
> tiny little daemon that reads a timing pulse-per-second and updates a
> shared memory segment.  It uses a few command line arguments to set the
> source port/type and shared memory segment destination; right now, that
> is done for the init script by a file in /etc/sysconfig.

And that's a bad thing to do. You're sourcing your configuration in an 
unsanitised environment. There's a huge number of ways that this can go 
wrong depending on the admin's local configuration, which is clearly 
undesirable.

> This is a small, light-weight daemon, and doesn't need a configuration
> file parser.  This is a valid way that Unix daemons have run for
> decades, and you are saying that should be removed.  I guess every small
> daemon now needs to include its own config file parser, replacing the
> already-existing getopt() call?  How is this "better"?

Nobody's said it should be removed. Lennart's said that it sucks, and I 
agree. But all of this would still be better with a simple config parser 
that's shared between any daemons that want it.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org