====== Problem with systemd-tmpfiles-setup service ======

In a **Debian 12 Bookworm** installation I faced some problems at bootstrap. Some services does not start basically because the **%%/run%%** hierarchy was not properly initialized with the required subdirectories. E.g. one OpenVPN service does not start beacuse the **/run/openvpn/** directory does not exists:

<code>
ovpn-office[2853]: Options error: --writepid fails with '/run/openvpn/office.pid':
    No such file or directory (errno=2)
</code>

An enlightening error message is displayed by **dmesg**:

<code>
systemd[1]: sysinit.target: Found ordering cycle on systemd-tmpfiles-setup.service/start
systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break
            ordering cycle starting with sysinit.target/start
</code>

I.e. the service **sysinit.target** cannot start due a service ordering problem, so Systemd decided to delete the **systemd-tmpfiles-setup.service**. The problem could be with other Systemd unit too, e.g. the **avahi-daemon.socket**:

<code>
systemd[1]: avahi-daemon.socket: Found dependency on systemd-tmpfiles-setup.service/start
systemd[1]: avahi-daemon.socket: Job systemd-tmpfiles-setup.service/start deleted to break
            ordering cycle starting with avahi-daemon.socket/start
</code>

Others problematic Systemd units can be: **sockets.target**, **basic.target**.

===== Analyzing Systemd =====

<code>
systemd-analyze verify default.target
</code>

The command highlights an **ordering cycle** problem, which causes the deleting of a service:

<code>
sockets.target: Found ordering cycle on avahi-daemon.socket/start
sockets.target: Found dependency on sysinit.target/start
...
sockets.target: Job avahi-daemon.socket/start deleted to break ordering
                cycle starting with sockets.target/start
...
</code>

Notice that the ordering (and the deleting choice) is not deterministic: on each execution the path of ordering (and deleting) may change.

The problem was introduced by this custom Postfix/Courier setup: 
**[[postfix_courier_authdaemon_debian_12]]**. In fact disabling the Systemd ''var-spool-postfix-var-run-courier-authdaemon.mount'' unit, solves the issues listed by systemd-analyze.

In this specific case the problem was completely solved changing the dependencies of the **[[https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html|mount unit]]** created to have the Courier socket inside the Postfix chroot. Instead of the strong ''Requires='' and ''After='' dependencies upon the courier-authdaemon.service, declaring the weaker ''Wants='' dependency sovled to cycle problem.