systemd: Is it wrong?

[Steve Dickson]

On 07/11/2011 01:11 PM, Lennart Poettering wrote:
> 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.
What would it take to change this?

> 
>>    * 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.
hmm.... Not sure nfs-utils wants to get tied into the D-Bus world...

> 
>>    * 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?
in /etc/sysconfig/nfsservices
set LOCKD_TCPPORT=234

In nfsservice.service

EnvironmentFile=-/etc/sysconfig/nfsservices
ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT

to work.

> 
>>    * 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.
ok... I will look into that...

steved.