systemd: Is it wrong?

[Steve Clark]

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 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
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 at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110710/13c4ce81/attachment.html