On 07/11/2011 01:11 PM, Lennart Poettering wrote: > On Mon, 11.07.11 12:55, Steve Dickson (SteveD@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
