systemd: Is it wrong?

[Lennart Poettering]

On Mon, 11.07.11 12:55, Steve Dickson (SteveD at redhat.com) wrote:

> 
> 
> 
> On 07/11/2011 05:03 AM, "Jóhann B. Guðmundsson" wrote:
> > On 07/11/2011 02:40 AM, Steve Dickson wrote:
> >> I truly truly truly hope so... but at the end of the day... I
> >> simply can't allow a new, untested (in a business environment)
> >> package destabilize a technology that is used by a large number
> >> of our community...
> > 
> > The longer it takes to get a native systemd unit files out there the 
> > more "untested" they will become.
> True... 
> > 
> > The faster they will be out there the more experience/exposer they will 
> > receive.
> Acknowledged.
> 
> > 
> > No rocket science behind that logic some would even go so far as calling 
> > that common knowledge so if you are truly worried about that, convert 
> > those legacy sysv init file and put the native systemd unit file out 
> > there, the sooner the better..
> Yes I am very concern systemd will effect how NFS started, shutdown,
> managed, and configured... Because at the end of the day, when all
> hell breaks lose, your name will not those bz and your reputation
> will on the line... 
>  
> > 
> > I think it's time that we hear from you explaining to us how systemd has 
> > brought doom and chaos to the nfs world, how it has destabilize nfs and 
> > left the *major subsystem* not working and it's citizens running for 
> > their lives, committing mass suicide on the side walks and the cities 
> > being overrun by zombies and the nfs world going down in flames...
> > 
> > What do you say?
> My concerns are will documented the bz:
>     https://bugzilla.redhat.com/show_bug.cgi?id=699040
> 
> But in a nut shell:
>    * There is no way to conditionally start and stop services/daemons
>      using a configuration variable.

True, and on purpose.

>    * There is no way to conditionally start and stop services
>      within as service.

Not true. Services can start other services, by queuing a job for that
via a D-Bus call (or via systemctl, a wrapper for that). However, I'd
avoid doing this.

>    * The variables read out of the EnvironmentFile are *always* 
>      character strings which means set LOCKD_TCPPORT=234 is
>      no longer possible. Losing that ability to set variable to 
>      integer values seem to like a giant step backwards.   

Hmm? Shell only understands strings, too. What precisely are you asking for?

>    * Being able to set a number of different config variables 
>      that will automatically build a valid command line to a 
>      given daemon.

You can do that. Subsituation of env vars is (on purpose) very simple in
systemd. If you need a programming language to spawn your service, then
use one: shell.

> Granted, these issues will not effect the stability of the actual
> daemon code, but they will destroy the "easy-of-use" factor. 

We disagree on that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.