I am filing a new bug report to keep this issue clean and simple. I will update the other one.
[PROBLEM:] After a reboot, 40% of the times, the D-Bus 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.
[ACTION] I have noticed a pattern that happens when this failure occurs. I have attached 2 files... The first with a successful reboot and the second with a failed reboot. I have included only messages from 'Started Message of the Day' to the problem area to keep it on target.
Hope this helps towards a solution.
Thanks
[UPDATE:] I have run countless reboots using a virgin droplet 2CPU 4GB. Installed only Virtualmin with clamd disabled and clamscan enabled. 3/10 times, I get a dbus error.
The results are inside the attached syslog-vanilla-virtualmin-2cpu4gb.zip_.txt file. Are you also finding this to be an issue in your installations with Ubuntu? If so, then this makes the default Virtualmin istallation quite unstable and unfit for production.
This is quite serious in my opinion. Your input is of great significance. Eagerly awaiting your responce.
Comments
Submitted by Rory Bremner on Thu, 06/20/2019 - 19:36 Comment #1
Submitted by andreychek on Thu, 06/20/2019 - 20:23 Comment #2
Howdy -- we're sorry to hear you're experiencing a DBus issue!
That doesn't sound like a Virtualmin issue that you're seeing there though. I'm not sure there's much we'd be able to do about that.
You may want to work with the DBus or Ubuntu community to get input on that, though you're also welcome to ask about that in the Forums here to see if any of the Virtualmin sysadmins have any ideas as to what's going on there.
Submitted by Rory Bremner on Fri, 06/21/2019 - 04:41 Comment #3
Submitted by Rory Bremner on Fri, 06/21/2019 - 04:45 Comment #4
Hey andreychek thanks for the prompt reply. The reason I am posting here is because this happens on a virgin droplet with only virtualmin installed. 3/10 reboots, result in a dbus error. If you still think that this is not a virtualmin issue then fine, you may close this issue. I have updated my initial post with an update and an attachment of the last 10 reboots on a 2CPU 4GB digitalocean droplet.
Submitted by Rory Bremner on Tue, 06/25/2019 - 06:50 Comment #5
I masked firewalld and disabled it.
I modified fail2ban to work with IPTables and added a service to keep iptables in sync with webmin. Robustness, usability and stability is where it should be again. Do you see any problems with this setup that I should be aware of?