JeffG's picture

When I boot up my Amazon EC2 instance, I can access the webmin using URL or direct IP address with :12321


After a few minutes, the browser I am trying to use will say site cannot be reached and/or connection refused. If I reboot the server, I can then connect once again. When this happens, I can still access SSH via public IP:12320.

Any idea why my webmin is becoming unavailable? I have deleted adn recreated several test instances but getting smae behavour.


I am all patched and updated.


Thoughts anyone? Thanks in advance!!

Jeremy Davis's picture

I can't say that I've had the same experience but I will have to test and see if I can reproduce this behaviour.

In the meantime here's some questions: Which browser are you using? Have you tried other web browsers? If not could you please? If so does that change things at all? It sounds like you may not even be getting the same message each time? Is that the case?

Also if you are able to help troubleshoot that'd be great. From the shell can you check that Webmin and stunnel are still running (stunnel should be but let's check):

service webmin status
service stunnel4 status
Also check to see that there are services listening on the relevant ports:
netstat -l | grep 12321
netstat -l | grep 10000
Both of these should show results. Obviously port 12321 is the port you connect to; it's where stunnel is listening for a connection. Port 10000 is Webmin's default port (it's hidden behind stunnel for extra security).

If all the above seems normal, perhaps just try restarting Webmin (and refreshing your web browser window) and see if anything changes.

service webmin restart

By default stunnel logging is turned off but we should be able to enable it fairly easy to see what might be happening there...

Finally the only other thing I can think of is are you using a good password? Poor passwords have resulted in users having their AWS servers hacked (brute force attack). The bad guys can often get in within minutes if you have a poor password. It's probably unlikely if you have set a good password but could be a possibility...

JeffG's picture

Thakns for reply Jeremy

When I run 

netstat -l | grep 12321

I get a reply after a fresh reboot. But after sevearl minutes and I run the command again, I do not get an output so I presume somehow someway, that port is closing or stopping? I am using the EC2 micro instance and my RAM usage is 93% but 0% swap file usage. 

When I run 

service webmin restart

I get 

	stopping webmin server in /usr/share/webmin/etc/webmin stop: 4: kill: no such process.

When I run /etc/webmin/stop , the service starts and I can access the publicIP:12321

I guess the question is, why is it crashing... It only runs for a few minute then crashes again...

Any thouhgts?

OnePressTech's picture

You said that when you run "service webmin restart" you get "kill: no such process". That would imply the webmin process is not running. You also said that running "/etc/webmin/stop" starts the service! I'm assuming you meant "/etc/webmin/start"?

Q1: What type of appliance is this. Some appliances require a higher minimum RAM than others and a Micro appliance may be too small?

Q2: Does your RAM peak at 93% usage or is that the steady-state RAM usage? If this is your steady-state RAM usage then you may be experiencing an OOM Killer issue. When RAM is low the OOM Killer will kill the process that is using the most RAM.

Suggestion: Temporarily launch the appliance as a small or medium sized instance and see if you still have the issue. You may be running out of RAM (OOM killer tripped) or you may be exhausting your CPU allocation for a Micro instance (AWS will temporarily shut off access).

Hope that helps :-)



Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

Please post the output of the commands that I note in my post above.

It would also be useful to know which version of TurnKey you are using. So please post the output of the following:

lsb_release -a
carlama25's picture

I'm haveng the same problem! 

Could you fix it?

Jeremy Davis's picture

Unfortunately though, it's really hard to assist diagnosing an issue without adequate information. So please share more information about the nature of the problem. Please see previous posts in this thread if you are unsure what information to post.

It's also worth noting, that whilst on face value the problem may appear to be the same as this one, it may be a different cause.

Add new comment