Hey Ryan,
I am not sure this is the right place to post. But this is the only webmin forums I have seen so far that comes close to public support.
This’ll do. Quite a lot of Webmin users here (and both Jamie and I are around…though I tend to be the only one of us that consistently reads the forums, while Jamie tends the Webmin mailing list far more than I). If we’re not able to get you straightened out, the best source for general Webmin support is the Webmin mailing list:
http://www.webmin.com/mailing.html
I’ve never heard of this particular problem before, and I’ve never seen it myself.
But, here’s a couple of things to try:
Try a different browser. If it’s happening on two different servers with wholly different operating system revisions (which are known to work fine, and are used successfully by thousands of Webmin users, myself included), then it might be time to try changing another variable.
Check DNS resolution on the server. I’ve never seen DNS trouble exhibit it just this way before, but I know that about 90% of “it doesn’t work!” or “it is slow!” problems in any networked service situation is due to DNS problems.
Login to your server, and run the following:
host yahoo.com
host 66.94.234.13
If both of those do not return immediately with sane answers, then DNS is a problem, and you’ll need to fix it. To really be sure DNS isn’t a problem, you’ll need to confirm that your client machine IP can be reverse resolved successfully.
You might also, after checking DNS, check to be sure your box isn’t being eaten up by some runaway process. I supposed I can imagine Webmin spawning its child process to service your requests and then being killed by the OOM killer (or just the browser timing out waiting for some swap thrashing to occur as the kernel tries to free up memory for those child miniserv.pl processes). Use “top” and “ps auxc” to see what’s running, and whether you have enough free memory for something useful to happen (remember that “free”, “buffers”, and “cached” are all usable memory, and can be considered available for this discussion).
Hmmm…while we’re going down this track, check to be sure those two tools haven’t been compromised such that you can’t trust their results:
rpm -V procps
If this returns anything, then your system has likely been compromised. (This doesn’t prove when it hasn’t been, but it almost certainly proves when it has.)