Webmin service process crashing and/or hanging

Versions where the problem was observerd:

<

blockquote> - Virtualmin: 3.93.gpl or 3.94.gpl - Webmin 1.590 - Linux: Debian 6 (Kernel: 2.6.32-5-openvz-amd64)

<

blockquote>

Status: 
Active

Comments

Howdy -- we've occasionally seen that behavior on OpenVZ based systems... it's typically a sign of a resource problem.

What output do you see from this command:

free -m

And can you paste in the contents of the file "/proc/user_beancounters"? Thanks!

# free -m
                    total       used       free     shared    buffers     cached 
Mem:           6144       3966       2177          0          0          0 
-/+ buffers/cache:       3966       2177 
Swap:                     0          0          0 
# cat /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt 
      378:  kmemsize                 32721366             63490091  9223372036854775807  9223372036854775807                    0 
            lockedpages                     0                  973  9223372036854775807  9223372036854775807                    0 
            privvmpages               1015967              1631647              1572864              1572864                22436 
            shmpages                   329418               723277  9223372036854775807  9223372036854775807                    0 
            dummy                           0                    0                    0                    0                    0
            numproc                        98                  166  9223372036854775807  9223372036854775807                    0 
            physpages                  457687               788223                    0  9223372036854775807                    0 
            vmguarpages                     0                    0  9223372036854775807  9223372036854775807                    0 
            oomguarpages               461906               801823  9223372036854775807  9223372036854775807                    0 
            numtcpsock                     20                  140     1801439850948198     1801439850948198                    0 
            numflock                      308                  323  9223372036854775807  9223372036854775807                    0 
            numpty                          2                    6  9223372036854775807  9223372036854775807                    0 
            numsiginfo                      4                   98  9223372036854775807  9223372036854775807                    0 
            tcpsndbuf                  362144              6732368  4611686018427387903  9223372036854775807                    0 
            tcprcvbuf                  327680              8518208  4611686018427387903  9223372036854775807                    0 
            othersockbuf               175712              3263848  4611686018427387903  9223372036854775807                    0 
            dgramrcvbuf                     0                 4360  9223372036854775807  9223372036854775807                    0 
            numothersock                  144                  558     1801439850948198     1801439850948198                    0 
            dcachesize                 889403              1384340  9223372036854775807  9223372036854775807                    0  
            numfile                      5772                11422  9223372036854775807  9223372036854775807                    0 
            dummy                           0                    0                    0                    0                    0 
            dummy                           0                    0                    0                    0                    0 
            dummy                           0                    0                    0                    0                    0 
            numiptent                      14                   20  9223372036854775807 9223372036854775807                    0 

Okay, you do have a decent amount of RAM in your "free" output, it looks like about 6GB.

However, note the "failcnt" field in the user_beancounters file... that's showing that your "privvmpages" resource has had "22436" failures.

Memory failures are pretty harsh, and can lead to services crashing when they don't get the RAM they request.

You may want to talk to your provider, and ask about raising your resource limits.

I am my own provider :) But I haven't found a sensible way to prevent these PRIVVMPAGES failcounts from staying at 0. However much memory one gives the system, it always seems to run up against the limit.

Do you have any tips?

Sorry, I'm unfortunately not familiar with setting up OpenVZ :-)

I'll offer that I prefer Xen and KVM, as they seem a little more, well, welcoming to the various processes running within them :-)

Were you to use those, you could even use the free version of Cloudmin to provision them.

Each of those supports using swap space as well, so you don't have to rely fully on RAM. That makes it so that even if you were to temporary run low on RAM, that's not an emergency that would cause processes to start crashing (since they could begin using that swap).

I wanted to go for KVM but wasn't able to get the bridged routing working and went with openvz as a temporary measure. was having trouble making the kvm visible to the outside world on a public ip. will be happy to try cloudmin if I can get around this issue.

didn't realize that openvz doesn't swap.

thanks for the advice.