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