Debian TC vote on init system coupling

Posted Feb 23, 2014 20:34 UTC (Sun) by mathstuf (subscriber, #69389)
In reply to: Debian TC vote on init system coupling by AngryChris
Parent article: Debian TC vote on init system coupling

A large amount of unit files should be usable directly from other distros (which should, ideally, push them upstream). One of the bullet points for systemd is that distros no longer need to write their own service management glue. Other than that, maintainers need to test that things work. That would be a good topic for a Debian wiki page.

Debian TC vote on init system coupling

Posted Feb 23, 2014 22:18 UTC (Sun) by set (guest, #4788) [Link] (13 responses)

A quick look under /usr/lib/systemd/system/ on my Gentoo box shows a plethora of unit files, which seem to cover all the daemons and such that I have installed. They certainly are not complex, so it seems unlikely that legacy /etc/init.d scripts will somehow persist for long once systemd has been chosen. And I am not even running systemd, Im running OpenRC. (Gentoo optionally supports systemd.)

Debian TC vote on init system coupling

Posted Mar 2, 2014 9:26 UTC (Sun) by elvis_ (guest, #63935) [Link] (12 responses)

My one wish is that all the config files go in /etc, not scattered all over the system. It drives me insane.

Debian TC vote on init system coupling

Posted Mar 2, 2014 14:26 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

*user* configuration should go into /etc and it does.

Debian TC vote on init system coupling

Posted Mar 8, 2014 6:25 UTC (Sat) by elvis_ (guest, #63935) [Link] (10 responses)

It is an artificial distinction, unit files are configuration wherever they go. It just makes it harder for users to figure out what is going on when they are hidden away from /etc

I would much prefer unitfile.default and unitfile.localchanges in the same directory.

Debian TC vote on init system coupling

Posted Mar 8, 2014 8:52 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (9 responses)

I personally believe the split is very useful, clearly separating customization done by administrator from distro defaults.
And systemctl make it dead simple to see where from configuration is gathered.

1) unit location is in the second line of status output:
$ systemctl status gdm
gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
…

2) If administrator does customistation by drop-in snippets, all are listed in next line:
$ systemctl status privoxy
privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities
Loaded: loaded (/usr/lib/systemd/system/privoxy.service; enabled)
Drop-In: /etc/systemd/system/privoxy.service.d
└─after-tor.conf

3) administrator can review his own changes in /etc/systemd/system. To see final unit, ”systemctl cat” will merge all the changes and present the unit from systemd's point of view.

It is actually quite easy and clear to see what's going on.

Debian TC vote on init system coupling

Posted Mar 8, 2014 15:53 UTC (Sat) by raven667 (subscriber, #5198) [Link] (8 responses)

I don't think this person is disagreeing with you about splitting the config files, the only concern, which is a subjective, stylistic one, is that the default files aren't in /etc, so a new administrator is going to look in /etc/systemd for configs and see some empty directories and have to search around more to find where the defaults are stored, if the defaults were also in /etc/systemd, in a subdirectory or whatever then they'd be slightly more discoverable. The downside is that it is more inviting to edit the default files rather than create override files which is going against the grain of how the files are organized, which is probably why it isn't done this way, to lower slightly the chance of a misconfig by someone editing the wrong file.

Debian TC vote on init system coupling

Posted Mar 8, 2014 17:05 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

The distinction between /etc/ which is user configuration and /usr which is what the distribution provides isn't merely a stylistic choice. If more programs adopt this convention, it makes it much more easier to understand what customizations have been done or snapshotting etc. There are other ways of handling it including storing /etc in a revision control system and package management specific tweaks but I would prefer if such ideas were baked in as common conventions.

Debian TC vote on init system coupling

Posted Mar 8, 2014 18:15 UTC (Sat) by dlang (guest, #313) [Link] (5 responses)

and systemd continues to throw away system administration conventions 'just because'

Debian TC vote on init system coupling

Posted Mar 8, 2014 18:21 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

You are making vague assertions 'just because'.

Debian TC vote on init system coupling

Posted Mar 8, 2014 23:42 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

Here's your system administration convention:

/etc = stuff the local administrator may change
/usr = stuff the local administrator shouldn't change

The distribution provides basic systemd units below /usr, and local changes to those systemd units, or all-new systemd units, go into /etc. Systemd figures out how these go together, and provides tools that make it easy to find the effective configuration that is actually being used. It is actually quite nifty.

Exactly how does systemd »throw away« anything? If anything, System V init is ignoring the convention by putting loads of stuff into /etc that is really quite difficult to change without producing a maintenance nightmare.

Debian TC vote on init system coupling

Posted Mar 9, 2014 4:19 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

Service startup is an administrator level activity, so configurations for service startups should be under /etc, including ones modified by the local administrator and those that are system defaults.

Debian TC vote on init system coupling

Posted Mar 9, 2014 5:13 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Agreed on everything except the last part. There is no particular reason defaults shipped by the distribution needs to be part of /etc at all and systemd is hardly the only program shipping system configuration defaults in /usr. Dozens and dozens of programs do that. In systemd, you can override only what you want to:

Ex:

--
/etc/systemd/system/httpd.service.d/restart.conf

[Service]
Restart=always
RestartSec=30

man systemd.unit more details

Debian TC vote on init system coupling

Posted Mar 9, 2014 13:25 UTC (Sun) by anselm (subscriber, #2796) [Link]

This is particularly useful because in the systemd setup the configuration files provided by the distribution are cleanly separated from the local settings made by the administrator.

With something like System-V init, everyone unloads their init files in /etc/init.d, and it is difficult for an administrator to (a) see whether any of these scripts have indeed been changed to better suit local preferences, and (b) maintain such changes across updates from the distributor. Systemd makes this much more obvious because anything under /etc is by definition a local change, and updates to the distributor-provided configuration in /usr do not run the risk of either obliterating the local changes or else requiring a tedious manual merge.

Debian TC vote on init system coupling

Posted Mar 8, 2014 18:29 UTC (Sat) by raven667 (subscriber, #5198) [Link]

Just because a decision is stylistic or subjective doesn't mean it's arbitrary, it means that there are pros and cons of each approach and depending on how you weigh the assumptions you may logically arrive at different answers from other people.

Certainly in this case there are pros and cons of each approach, which I tried to highlight and provide some guesses of possible rationale for each, none of which was "just because".