If I try to use vi in one of my VEs, I get an odd error, but the 
/proc/user_beancounters don't show any errors, so I'm not sure what I'm 
exceeding.

Here is the error vi spits out:

E297: Write error in swap file
E303: Unable to open swap file for "rc.local", recovery impossible
"rc.local" 17 lines, 387 characters
Press ENTER or type command to continue

and here is my user_beanconters immediately after I quit out of vi:

root@ftp:/var/run# cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    
failcnt
      106:  kmemsize        1167508    1524641    2752512    
2936012          0
            lockedpages           0          0         32         
32          0
            privvmpages       14146      21232      40960      
81960          0
            shmpages             57         57       8192       
8192          0
            dummy                 0          0          0          
0          0
            numproc              30         39         96         
96          0
            physpages          2798       3561          0 
2147483647          0
            vmguarpages           0          0       6144 
2147483647          0
            oomguarpages       2798       3561       6144 
2147483647          0
            numtcpsock            6          8         80         
80          0
            numflock              1          4        100        
110          0
            numpty                1          1         16         
16          0
            numsiginfo            0          2        256        
256          0
            tcpsndbuf             0      51060     319488     
524288          0
            tcprcvbuf             0       2220     319488     
524288          0
            othersockbuf       4440      10000     132096     
336896          0
            dgramrcvbuf           0        684     132096     
132096          0
            numothersock          4         12        120        
120          0
            dcachesize            0          0    1048576    
1097728          0
            numfile             582        731       2048       
2048          0
            dummy                 0          0          0          
0          0
            dummy                 0          0          0          
0          0
            dummy                 0          0          0          
0          0
            numiptent            14         14        128        
128          0

It might be something really obvious, but I'm not seeing it :-(

This doesn't happen in all of my VE's so I guess it must be something to 
do with the amount of memory I have allocated to this one (or 
something), but nothing seems to be getting too close to the limit.

Steve

Steve Hodges wrote:
> E297: Write error in swap file
> E303: Unable to open swap file for "rc.local", recovery impossible
> "rc.local" 17 lines, 387 characters

That's vi saying that it can't save a backup of the file (yeah, "swap 
file" really intuitive) That's probably just a permissions issue. Are 
you able to manually create and then delete a fake swap file named 
.rc.local.swp ?

-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA

On 27/08/2007 9:16 AM, Gregor Mosheh wrote:
> Steve Hodges wrote:
>> E297: Write error in swap file
>> E303: Unable to open swap file for "rc.local", recovery impossible
>> "rc.local" 17 lines, 387 characters
>
> That's vi saying that it can't save a backup of the file (yeah, "swap 
> file" really intuitive) That's probably just a permissions issue. Are 
> you able to manually create and then delete a fake swap file named 
> .rc.local.swp ?
>
It turned out to be a disk quota issue.

GOOD: the VE didn't chew up all the available disk space (as it would 
have in a couple of hours)
BAD: the violation of the disk quota doesn't show up in user_beancounters

I discovered it when I tried to create a file using echo xxxxx > file

Steve

> It turned out to be a disk quota issue.

Sounds right. Glad you figured it out.


> BAD: the violation of the disk quota doesn't show up in user_beancounters

Ah, quite true.

At my work site, we use Nagios to monitor all of our VEs for general 
health, as we would any other systems: check the free space, make sure 
the database server is running, make sure that DNS is resolving, etc. 
Our VEs are leased out to untrusted customers who sometimes attempt 
amateur system administration, so some sanity/health checks are helpful 
on general principles. :)

-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA

Steve Hodges wrote:
> On 27/08/2007 9:16 AM, Gregor Mosheh wrote:
>> Steve Hodges wrote:
>>> E297: Write error in swap file
>>> E303: Unable to open swap file for "rc.local", recovery impossible
>>> "rc.local" 17 lines, 387 characters
>>
>> That's vi saying that it can't save a backup of the file (yeah, "swap
>> file" really intuitive) That's probably just a permissions issue. Are
>> you able to manually create and then delete a fake swap file named
>> .rc.local.swp ?
>>
> It turned out to be a disk quota issue.
>
> GOOD: the VE didn't chew up all the available disk space (as it would
> have in a couple of hours)
> BAD: the violation of the disk quota doesn't show up in user_beancounters
>
It shows in df (or df -i) -- standard UNIX/Linux tool; it is all
described in http://wiki.openvz.org/Resource_shortage (which I guess I
should add to "must read" category.

See, ff there is a standard way of seeing something, why invent
something new and unique? For disk space there is such a tool, for
beancounters there was no, since beancounters only appeared in OpenVZ.

>From the host system though there is a way to see all per-VE disk quotas
and their usage -- cat /proc/vz/vzquota

Since we're on the topic, I thought I'd pipe up for Steve's benefit 
about a small matter which I found baffling for a few days...

If you run "df -k" in a VE, you will often get a different answer than 
vzquota. This is because vzquota doesn't keep to-the-moment statistics 
in its cache file. You must run "vzquota stat VEID" in order to have the 
cache updated; then vzquota will report the correct usage. This is in 
the Wiki, but I thought to save you some time. :)

-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA

On 28/08/2007 12:14 AM, Gregor Mosheh wrote:
> Since we're on the topic, I thought I'd pipe up for Steve's benefit 
> about a small matter which I found baffling for a few days...
>
> If you run "df -k" in a VE, you will often get a different answer than 
> vzquota. This is because vzquota doesn't keep to-the-moment statistics 
> in its cache file. You must run "vzquota stat VEID" in order to have 
> the cache updated; then vzquota will report the correct usage. This is 
> in the Wiki, but I thought to save you some time. :)
>
Thanks :-)

And for the benefit of Kir, I wasn't intending the GOOD/BAD thing wasn't 
intended as a criticism of openvz.  It was really only bad because I had 
become fixated on the user_beancounters as a diagnostic and had 
forgotten about all the other good tools :-)  The error from vi sort of 
pointed me at a memory issue which didn't help much either.

However I was extremely grateful that my silly error in causing the VE 
to consume about 8 GB per hour had stopped at the quota limit of 40 GB 
rather than consuming all free space on that partition.


Steve