Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 09.05.2019 um 17:20
in
Nachricht <20190509152036.GB5854@gardel-login>:
> On Do, 09.05.19 12:22, Ulrich Windl (Ulrich.Windl@xxxxxx‑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.

It just keeps the balance in the universe after all those "systemd is sooo
great" enthusiasm ;-)
Maybe you can make me change my mind...

> 
>> 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!

Yes, that's the "introduction to my personal frustration". I kept out the fact
that the list has a non-working "-request" address. That might add to the
overall impression I git so far...

> 
>> 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.

Yes I got that once I understoood what the error message is acutally trying to
tell me ("absolute paths not allowed", you explained that earlier to me).

> 
> 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

Please let the admin decide what "well-organized" is.

> the various services follow established standards and place their
> stuff there and don't make up entirely random dirs outside of the
> typical hierarchy.

There's a difference between "random dirs" and subdirectories.

> 
> 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.

OK, so I wasn't that wrong with my claim. Unfortunately with an enterprise
distribution you don't want to install updates that make you loose support.
(The current most-recent SLES 15 is at systemd v234, unfortunately)

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

It it because you don't like sub-directories, or is it to save four bytes?
;-)

> 
>> 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.

Not really: You can't verify a unit file while it's not "installed". Comare it
to validating an XML file, for example.

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel