Systemd programming part 1: modularity and configuration

Posted Feb 5, 2014 23:54 UTC (Wed) by zuki (subscriber, #41808)
Parent article: Systemd programming part 1: modularity and configuration

The daemon could read a configuration file (say /etc/nfsd.conf) directly...

Systemd programming part 1: modularity and configuration

Posted Feb 6, 2014 4:40 UTC (Thu) by zenaan (guest, #3778) [Link] (2 responses)

Many daemons provide just such an option.

Also:

> While systemd can certainly read these same configuration files (with the EnvironmentFile directive) and can expand environment variables in command line arguments to programs, it lacks any sophistication. Non-optional parameters are easily handled, so:
>⋅
> /usr/sbin/rpc.nfsd -n $USE_KERNEL_NFSD_NUMBER
>⋅
> would work as expected, but optional parameters cannot be managed so easily. While the Bourne shell (which interprets SysVinit scripts) and Upstart would both support:
>⋅
> /usr/sbin/rpc.mountd ${MOUNTD_PORT:+-p $MOUNTD_PORT}

So change MOUNTD_PORT to MOUNTD_PORT_ARG:

/usr/sbin/rpc.mountd $MOUNTD_PORT_ARG ...

Where eg, /etc/default/my-service.conf contains eg:

MOUNTD_PORT_ARG="-p 12345"

I know it's clunky, but it is trivial to implement, and the author Neil _is_ talking transition here ("longer term" vs "short-term")...

Systemd programming part 1: modularity and configuration

Posted Feb 6, 2014 6:00 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

That does seem very "transitional". One of the benefits that you get with the config file arrangement for systemd is a standard supported way to override configs without conflicting with the packaged default files. You could create a new service file in /etc/systemd which changes the default command to include whatever arguments you want, and then audit any such changes with systemd-delta to show what you've hand-edited and exactly where it differs from the default. That removes a lot of the need for /etc/default or /etc/sysconfig files in the first place, which was the inherent conflict when editing /etc/init.d scripts between your edits and the packaged versions.

Systemd programming part 1: modularity and configuration

Posted Feb 6, 2014 6:49 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Sometimes I need to shut my mouth and read the article rather than just the Unread Comments interface as then I would have seen that Neil had this well under control in the main article and wouldn't have been redundant.

Now that I've read the article I understand Neil's point but it is my opinion that giving the system admin good tools to audit changes which diverge from the default is sufficient, although sure there could be an even better system which doesn't even require the audit and integration, I'd rather keep the system simple, his example of having units run scripts to generate environment files which alter the behavior of other units is too abstract and complex (hacky) for me.

The straightforwardness of systemd-delta appeals to me, in the same way that other tools which show you diffs between the packaged and modified version of a config and allow you to merge the changes when you update.

Systemd programming part 1: modularity and configuration

Posted Feb 7, 2014 21:54 UTC (Fri) by bfields (subscriber, #19510) [Link] (1 responses)

"The daemon could read a configuration file (say /etc/nfsd.conf) directly..."

Yeah, I think that would be better in the long run.

Code at git://linux-nfs.org/nfs-utils, patches to linux-nfs@vger.kernel.org....

Systemd programming part 1: modularity and configuration

Posted Feb 7, 2014 22:45 UTC (Fri) by neilbrown (subscriber, #359) [Link]

Looking forward to reviewing those patches.

Make sure they include plugins for all knows configuration UIs to work with this new config file.

Given that

- configurators can already read/write environment files
- systemd can already load them into the environment, as can the shell
- daemons can get them out of the environment using "getenv()", which is already in the standard library

there seems little point in creating new config files for any configuration that can be provided by a simple environment file.

What is why I won't be providing patches to read config files.