>>> Lennart Poettering <lenn...@poettering.net> schrieb am 09.05.2019 um 17:20 in Nachricht <20190509152036.GB5854@gardel-login>: > On Do, 09.05.19 12:22, Ulrich Windl (ulrich.wi...@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.
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 firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel