[systemd-devel] Antw: [EXT] Re: tmpfiles chicken-egg problem

[Lennart Poettering]

On Mi, 26.08.20 16:01, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > Hence, if this happens your setup is borked in some way: some entries
> > in tmpfiles.d/ drop‑ins are owned by users/groups managed by LDAP. Fix
> > that, and everything should be fine.
>
> It's all transitional in some way. In the past a system user was a user with a
> UID below the UIDs given to interactive users.

This didn't change, system users are still the ones with the low UIDs.

> Directories existed right from the beginning of the boot, and the
> user had to be known when a corresponding process had to be
> started. Not earlier. Systemd redefined the world, so don't point at
> the world if things are broken now...

Nah, the the major difference is that we document this behaviour, and
previously it just failed miraculously with no explanation in the
docs, because there were no docs on the requirements.

tmpfiles.d/ replaces a bunch of early boot shell scripts, that's
all. tmpfiles.d/ is run in early boot, just like those early boot
shell scripts it replaces. And what applied to them applies to
tmpfiles.d/ here, except we actually spell it out in the man page and
the docs otherwise.

And besides that, we actually push people towards using
RuntimeDirectory=, StateDirectory=, … and stuff so that these dirs are
created when the service is started and not earlier, for services
where that works.

Lennart

--
Lennart Poettering, Berlin