[systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)

[Lennart Poettering]

On Do, 09.05.19 12:22, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> Hi!
>
> I had to subscribe to this list, even though I'm no systemd
> fan. Still I'll have to deal with it as the distribution we use
> switched to systemd...

Fantastic lead-in. This is a perfect intro if you are asking for help,
it creates the outmost desire in everyone who could help you to do so
right-away.

> I'm porting my LSB code to systemd, and I'm having some
> trouble. Cause of the trouble (and possible reason for systemd's
> unpopularity) seems to be rather arbitrary restrictions without
> reasoning (which is completely against the GNU spirit of seeking for
> limitless software).

Hmm, the second paragaph even manages to improve upon the first. Your
reader is now as enthusiastic as they could be to help your ASAP!

> To be concrete: Why isn't it allowed to use an absolute path for
> RuntimeDirectory, and wy isn't even a relative path allowed? In my
> case I have a multi-instance daemon, where the instances can be zero
> to many. To avoid namespace conflicts, I created a /var/run/<my_pkg>
> directroy where all the instances put their stuff (in separate
> directories each)

The "Runtime" in "RuntimeDirectory" should clarify that /run is where
such dirs are created, hence we don't accept absolute dirs: the prefix
must be /run, hence why specify it. If you want systemd to create a
dir elsewhere, use StateDirectory= (which creates it in /var/lib) or
CacheDirectory= (which creates it in /var/cache) or
ConfigurationDirectory= which creates it in /etc.

These four options map to the four main locations to place service
data resources in. Well organized services only use those four places,
since they come with clear life-cycle and semantical definitions, and
get first class support via the four settings. It's a gentle push that
the various services follow established standards and place their
stuff there and don't make up entirely random dirs outside of the
typical hierarchy.

Before systemd v235 the RuntimeDirectory= setting did not support
relative paths with "/" included. Starting with 235 it will accept
them. Hence, please consider updating, you apparently run an older
systemd version.

Note that "/var/run" is a legacy alias for "/run". It's highly
recommended not to use the former anymore.

> Despite of that I'm missing a "systemctl validate ..." command. That
> way I wouldn't need to execute start, status, stop, just to find out
> that some settings are rejected.

"systemd-analyze verify" exists. Since a long long time.

Lennart

--
Lennart Poettering, Berlin