Re: systemd: Is it wrong?

[Steve Clark <sclark@xxxxxxxxxxxxx>]

On 07/10/2011 05:35 PM, Matthew Garrett wrote:

On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote:

Once upon a time, Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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 

Says you. It has seemed to work OK for the last 25+ years. I don't ever remember having a problem
in my 25+ years of working with UNIX/LINUX with the existing initscripts. Where are the BZ reports
that we are fixing with systemd?

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.

--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@xxxxxxxxxxxxx
http://www.netwolves.com

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel