Systemd programming part 2: activation and language issues [LWN.net]

Systemd programming part 2: activation and language issues

Posted Feb 14, 2014 21:29 UTC (Fri) by neilbrown (subscriber, #359)
In reply to: Systemd programming part 2: activation and language issues by mathstuf
Parent article: Systemd programming part 2: activation and language issues

Hi,
thanks for highlighting that. It is a relevant example that I hadn't fully explored.

Clearly Exec{Start,Stop}{Pre,Post} (and multiple others such as WorkingDirectory) are permitted in both the [Service] section and the [Socket] section. However they have the same meaning in both sections, and no unit file can have both sections, so there would still be no ambiguity if the section headings were absent. The precise meaning is determined by the suffix of the unit file.

(and I did wonder why those "multiple others" were not in an [Exec] section, seeing they are documented in systemd.exec - there is some fancy m4 preprocessor code to duplicate a collection of Directives across multiple sections in src/core/load-fragment-gperf.gperf.m4)

to post comments

Systemd programming part 2: activation and language issues

Posted Feb 15, 2014 17:29 UTC (Sat) by mbunkus (subscriber, #87248) [Link]

> Clearly Exec{Start,Stop}{Pre,Post} (and multiple others such as WorkingDirectory) are permitted in both the [Service] section and the [Socket] section. However they have the same meaning in both sections, and no unit file can have both sections, so there would still be no ambiguity if the section headings were absent.

My guess is that it's more about future extensibility without breaking compatibility. While it may be true that there are no conflicts today doesn't mean they won't invent features that allow multiple sections with the same option names. These can be added easily with new sections, but if there were no sections then they might be forced to chose awkward names or prefix quite a lot of those new options, neither or which would improve the ease of use.

Systemd programming part 2: activation and language issues

Posted Feb 20, 2014 17:54 UTC (Thu) by cg909 (guest, #95647) [Link] (1 responses)

I think the separation into the sections is more for clearifying what the directives apply to.

Directives in [Unit] apply to the dependeny tree and define general properties of the unit.
Directives in [Install] are only used when running systemctl enable/disable and have no other direct effect.
Directives in [Service], [Socket], ... define the behaviour when the unit is run. And as the allowed directives are different between unit types the sections also are named differently. This little redundancy may also help catching copy&paste errors between unit files.

Sections like [Exec], [Kill], ... would only group some related directives without providing context. Currently it would also split the execution environment directives and the Exec, ExecStartPre, etc. directives into different sections.

Systemd programming part 2: activation and language issues

Posted May 28, 2014 23:00 UTC (Wed) by Duncan (guest, #6647) [Link]

[Not that many will see this so long after original publishing, but for the benefit of people googling, etc...]

This.

When invoking systemctl enable/disable, systemctl/systemd only has to look at [install], other sections can be ignored.

Similarly, when systemd is constructing its dependency tree, it only has to look at the [unit] section, [install] and [service], etc, sections can be ignored. And when it's actually invoking the unit, only the [service], [socket], etc, sections as appropriate, must be considered, [install] and [unit] can be ignored.

While I've no idea whether systemd is actually coded this way, from back in my MS days I know their ini-file APIs were setup to work exactly that way. The API allowed you to open a particular ini file, then specify section and key (IIRC they used the term "value", which always confused me) to return or set, with its value (which they termed "data", as "value" referred to the key) then returned or set. Other sections might as well not have existed at all, and in fact, could belong to entirely different applications (as was the case in MS Windows 2.x I believe, when all sorts of apps had sections in win.ini, before 3.x introduced dedicated application ini files).

So access is (at least conceptually) by section and then key, and if key names don't overlap between sections, it's only to avoid human confusion, not because they couldn't, as to the application, if they're in different sections they are (or should be) entirely different things, regardless of what they're named.

Duncan