<i>Once you have a dependency you can have circular dependencies.</i><p>Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed.<p>(Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.)<p><i>And once you rely on the init systems to establish ordering rather than having everything just start up in a deterministic order in simple single-threaded script, you can have race conditions where things happen to work on one machine but not another.</i><p>Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd&#x27;s execution model and transactional object system exacerbate non-determinism in ordering results.<p><i>I don&#x27;t understand why I would want separate daemons for collection and rotation, at least for dmsg, kmsg, and syslog. logrotate always had a bunch of race conditions; it was never a great design.</i><p>They&#x27;re not separate daemons.<p><i>My real criticism of systemd is that they made no effort at portability outside of Linux (and I don&#x27;t buy their arguments about why it&#x27;s too hard.)</i><p>That&#x27;s a <i>horrible</i> criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation.