Firewall bouncer fails to start (systemd ordering cycle)

I’m on Ubuntu 22.04

I have crowdsec and crowdsec-firewall-bouncer installed and working. But after a reboot, systemd complains that the crowdsec-firewall-bouncer is causing an “ordering cycle”. The effect is that systemd doesn’t start crowdsec at all.

The only workaround I was able to find is to disable the automatic start of the firewall bouncer and start it manually after each boot.

Here is the relevant dmesg output:

[    4.377144] systemd[1]: crowdsec-firewall-bouncer.service: Found ordering cycle on crowdsec.service/start
[    4.381432] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on sysinit.target/start
[    4.385870] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on cloud-init.service/start
[    4.387975] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on systemd-networkd-wait-online.service/start
[    4.391077] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on systemd-networkd.service/start
[    4.394070] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on network-pre.target/start
[    4.396484] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on netfilter-persistent.service/start
[    4.401248] systemd[1]: crowdsec-firewall-bouncer.service: Found dependency on crowdsec-firewall-bouncer.service/start
[    4.405390] systemd[1]: crowdsec-firewall-bouncer.service: Job crowdsec.service/start deleted to break ordering cycle starting with crowdsec-firewall-bouncer.service/start

I noticed that removing the “Before” dependency may be what’s causing the issue.

If I edit the below file the issue goes away:

vi /etc/systemd/system/crowdsec-firewall-bouncer.service

change:

“Before=netfilter-persistent.service”
TO
“Before=”

I can’t see any issues as a result of doing the above change. Can anyone think of a better workaround or a permanent solution?

1 Like

Same issue here, even caused NetworkManager to fail at reboot. This change fixed the issue.

Same issue for me. I noticed that there is an existing open issue on github about this dependency causing problems but not specifically this “ordering cycle” issue we experienced. I put a note there so developers are aware.