On Mon, Jul 18, 2011 at 3:34 PM, Tom Lane <tgl@xxxxxxxxxx> wrote: > Well, if they didn't need fixed before, they'll certainly need fixed > when you make them start keeping their configuration info someplace else Yeah -- daemons that can be configured with commandline options or envvars are Just Fine. If those options can be tweak without getting into conflict with the rpm-maintained init script / service file, that is actually _a seriously good feature_. My sysadmin self wants to have a way to override any vars defined in the service file, preferrably in a directory similar to sysconfig. Lennert's review of what we have currently in /etc/sysconfig is correct -- a horrid mess. A cleanup is needed. But we can't do away with the ability to override the shipped configuration. For example - I often use those overrides to point a daemon to a different config file or dir, so as to make config changes without concern of what installed pkgs may do. This insulates the setup from configfiles that aren't marked as config, or new files dropped into a conf.d directory. I have used the same technique in cases where I'd run several instances of the same daemon in different ports or intefaces, and the init script was too scary to copy and edit (and maintain going forward). With service files being simpler, this use case goes away - cp the service file and editing it becomes a lot more doable. > than /etc/sysconfig. This proposal sounds more like "wait, systemd has > not yet broken everything in sight, how can we solve that problem?" Heh -- I do like systemd replacing init and streamlining some things. But there's a limit to everyone's comfort on the speed of change... folks could take the world domination track /a little bit slower/. There's also a lot to learn from completing one stage before taking the next 5 :-) m -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel