2

[SYSTEM]

Virgin DigitalOcean droplet Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-52-generic x86_64) with all updates with latest Virtualmin and nothing else.

How would you suggest I proceed with this?

[PROBLEM] After a reboot, 30% of the times, the D-Bus & FirewallD will fail like so:

Jun 20 09:28:35 ns1 networkd-dispatcher[679]: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory 
Jun 20 09:28:35 ns1 systemd[1]: networkd-dispatcher.service: Main process exited, code=exited, status=1/FAILURE Jun 20 09:28:35 ns1 systemd[1]: networkd-dispatcher.service: Failed with result 'exit-code'. 
Jun 20 09:28:35 ns1 systemd[1]: Failed to start Dispatcher daemon for systemd-networkd.

Contrast this with the times it succeeds:

Jun 20 09:30:16 ns1 networkd-dispatcher[678]: No valid path found for iwconfig
Jun 20 09:30:16 ns1 networkd-dispatcher[678]: No valid path found for iw 
Jun 20 09:30:16 ns1 networkd-dispatcher[678]: WARNING: systemd-networkd is not running, output will be incomplete. 
Jun 20 09:30:16 ns1 systemd[1]: Started Dispatcher daemon for systemd-networkd. 
Jun 20 09:30:16 ns1 systemd[1]: Started firewalld - dynamic firewall daemon.

[BACKGROUND] 'Networkd-dispatcher is a dispatcher daemon for systemd-networkd connection status changes.... The daemon listens for signals from systemd-networkd over dbus'

[THEORY] So DBus does not start and networkd-dispatcher.service depends on it to service signals... When 'Failed to start Dispatcher daemon for systemd-networkd.', firewalld croaks and maybe other things I guess.

[PATTERN] I have noticed a pattern that happens when these failures occurs.

[FirewallD reports:] Failed to list zones : Error: DBUS_ERROR: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
Jun 21 05:54:11 ns1 kernel: [ 8.398419] systemd[1]: firewalld.service: Found ordering cycle on dbus.socket/start
Jun 21 05:54:11 ns1 kernel: [ 8.404282] systemd[1]: firewalld.service: Found dependency on sysinit.target/start
Jun 21 05:54:11 ns1 kernel: [ 8.424332] systemd[1]: firewalld.service: Found dependency on cloud-init.service/start
Jun 21 05:54:11 ns1 kernel: [ 8.438320] systemd[1]: firewalld.service: Found dependency on systemd-networkd-wait-online.service/start
Jun 21 05:54:11 ns1 kernel: [ 8.497168] systemd[1]: firewalld.service: Found dependency on systemd-networkd.service/start
Jun 21 05:54:11 ns1 kernel: [ 8.505811] systemd[1]: firewalld.service: Found dependency on network-pre.target/start

[FirewallD reports:] Failed to list zones : FirewallD is not running
Jun 21 05:44:39 ns1 kernel: [ 7.396133] systemd[1]: network-pre.target: Found ordering cycle on firewalld.service/stop
Jun 21 05:44:39 ns1 kernel: [ 7.408784] systemd[1]: network-pre.target: Found dependency on basic.target/start
Jun 21 05:44:39 ns1 kernel: [ 7.418770] systemd[1]: network-pre.target: Found dependency on sockets.target/start
Jun 21 05:44:39 ns1 kernel: [ 7.455484] systemd[1]: network-pre.target: Found dependency on lxd.socket/start
Jun 21 05:44:39 ns1 kernel: [ 7.470305] systemd[1]: network-pre.target: Found dependency on sysinit.target/start
Jun 21 05:44:39 ns1 kernel: [ 7.476614] systemd[1]: network-pre.target: Found dependency on cloud-init.service/start

1 Answer 1

1

I just disabled and masked firewalld and went back to IPTables. No problems after that.

I had to change fail2ban to work with IPTables by commenting out :

# banaction=firewallcmd-ipset

in /etc/fail2ban/jail.d/00-firewalld.conf - Do not delete the file.

Then I setup a new service to save and restore IPTables on shutdown and reboot as I describe here:

Running commands on shutdown/restart Ubuntu 18.04

The reason I did not use iptables-persistent was because I wanted to integrate IPTables with Webmin which uses /etc/webmin/firewall/iptables.save and /etc/webmin/firewall6/ip6tables.save as temporary files to edit iptables.

By using my custom service I could use webmin to edit and apply iptables and on shutdown/reboot I saved iptables and restored them back.

Finally I had to add a fix to my service in order to clear out all fail2ban chains and rules, because on reboot f2b would add them again. For this you can follow my solution here:

REGEX: flush a number of related chains in iptables

1
  • Googling lead me here. Turns out for me it was a problem with firewalld and cloud-init fighting during boot on my AWS EC2 instances. More on this here, here, and here.
    – Xunnamius
    Sep 11, 2023 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .