Many NixOS modules now rely on systemd.tmpfiles.rules to set up files and directories needed for their service units to start. There used to be documentation advising against doing so, but that documentation was removed in 2017 in 43404d9, and in a quick search I found quite a few recent merged pull requests adding more uses of tmpfiles.d.

However, a 2014 patch against systemd by @edolstra (NixOS/systemd@91702db) makes tmpfiles.d unreliable for this purpose.

Normal systemd service units automatically depend on sysinit.target being reached Before the service. Upstream's systemd-tmpfiles-setup.service also explicitly declares that it must finish Before the sysinit.target unit. So normally services can rely on their tmpfiles having been created before the service starts.

In the NixOS fork of systemd, systemd-tmpfiles-setup.service no longer has a Before dependency declared on sysinit.target, which means that regular services can start before systemd-tmpfiles has finished. So there's a race condition that may sometimes prevent a service from starting.

In practice, systemd-tmpfiles is pretty fast, and even if a service fails to start systemd will probably retry it, so observing this bug in the wild is probably pretty unlikely. Still, I'd be a lot happier if this race condition were closed entirely.

The original commit message said that this patch was to avoid an indirect dependency from sshd.service on local-fs.target, because that interferes somehow with the NixOps send-keys feature. But it didn't explain why that was a problem, so I can't tell whether it's still an issue today. If it's still important, there are probably better ways to fix it, like perhaps setting DefaultDependencies=no on sshd.service and explicitly listing its true dependencies, but I can't be sure without an explanation of the underlying NixOps issue.

I'd encourage reverting NixOS/systemd@91702db and its rebased equivalents in any branches that are still used by supported versions of NixOS. I'm happy to help brainstorm alternative fixes that don't have such widespread side effects, given some pointers on what problem this patch was actually trying to solve.