Webmin/Virtualmin UI on port 10000 gives a connection refused after a few hours


I have been running Virtualmin on a VPS for a few years now. I moved over to DigitalOcean and recreated a new Virtualmin VPS.

Everything was working well until I noticed that I am unable to access the UI on port 10000.

All the other virtual servers work fine and are responsive.

Doing service webmion restart did not do anything and the only thing that seems to fix the issue is rebooting the server.

I also disabled the firewall ufw disable and got the same result.

I reinstalled the VPS 2 times and I am getting the exact same issue.

Anybody ever get this issue?

Any help will be very appreciated.

Thank you! :slight_smile:

Dollars to donuts it’s the OOM killer.

How much memory do you have? Check dmesg (this is a command to read the kernel log) for out of memory errors.

HUmmm… I think you are right…

Here is the output:

[625146.900678] [19121] 1003 19121 101292 4899 139 3 0 0 php-cgi7.0 [625146.900680] [19203] 114 19203 192713 130595 322 4 0 0 clamd [625146.900682] [19207] 0 19207 12235 474 28 3 0 0 cron [625146.900684] [19208] 0 19208 1127 176 8 3 0 0 sh [625146.900685] [19209] 0 19209 26820 3821 26 3 0 0 monitor.pl [625146.900687] Out of memory: Kill process 19203 (clamd) score 515 or sacrifice child [625146.902109] Killed process 19203 (clamd) total-vm:770852kB, anon-rss:521720kB, file-rss:660kB
So the solution would be to up the memory? It's funny because I am running a minimal install without email service, CLAMD should not be active and not running BIND either. Just hosting 4 sites with minimal traffic...

Hosted on a DigitalOCean droplet with 1GB ram and 1vCPU.

1GB is usually sufficient for a system without clamd/spamd. I’d make sure neither is running and also check top for the processes using the most memory.

You can check the low memory guide for a few tips on reducing the size of Apache, and you could also tweak your database settings. Another option is to create a swap file, which adds more memory by way of disk storage…this should be treated as “last resort” memory, as it is much slower than real memory, but it can help avoid random process destruction by the kernel.


You may also have an application that has a memory leak. It’s much less common in scripting languages commonly used for web apps, but not impossible. In OOP programs, it’s possible for programs to grow due to dangling references to objects. Now that most web applications including PHP and Perl and Ruby and Python and the like run under their own long-running app server, this becomes possible (when web apps restarted on every request, even a large memory leak would be ignorable because the process lasted such a short time).