systemd: Is it wrong?

[Steve Dickson]

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.

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

   * 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.   

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

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

My admins have to tweak one file and start (or restart) the 
service and BOOM everything just works... Its a two step 
process that has mature in time that has become fairly seamless 
and straightforward. This is what I'm concern that systemd 
will destroy. 

steved.