1

[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
0

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.