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. > * 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
