Thanks for ping. I'm not sure I understand – have you ran into some issues? There's tmpfiles spec that should ensure existence of all three. The one for cache was added here as well to

# Ensure correct ownership in case UID or GID changes.

because of ae74a0e. The other two didn't exist before that commit, so they weren't added in the same way.

To be clear, I see no harm in adding this, so I'm mainly curious. (and perhaps the comments are a bit confusing in combination with these "invisible" tmpfiles rules)

For some reason the files weren't created on my system. Kept getting CHDIR errors for (/var/lib/knot-resolver) and then errors about /run/knot-resolver not existing for the control.

It actually looks like I'm missing /etc/tmpfiles.d/knot-resolver.conf.

Seems like the problem is that the derivation being used has a symlink to the lib/ directory and it doesn't end up propagating. Using the unwrapped derivation gives me the file in tmpfiles.d.

Oh, and lib/systemd/ does get applied? (from systemd.packages = [ package ];)

EDIT: no, that implementation seems safe. I'm looking into making systemd.tmpfiles.packages resilient to this.

#95565 was merged, which should fix the knot-resolver tmpfiles not being applied.

Even on master, the permissions in the kresd@ template unit differ with what's in the tmpfiles file. tmpfiles will be applied once on boot, and on each system activation, whereas systemd will apply *DirectoryMode when starting the service, too (thus shadowing the tmpfiles).

@vcunat I think we can use only the per-unit directives here. I sent a patch to upstream at knot-resolver@labs.nic.cz - not sure how to exacty send contributions there. Also opened https://gitlab.nic.cz/knot/knot-resolver/-/issues/596.

Yes, I think on NixOS the kresd service can abandon using tmpfiles in favor of these, though I can't really see any practical differences.