QUOTAUGIDLIMIT is set to 3000 in the containers where it is set at all. It
doesn't seem to have any bearing on the problem though - some containers
with this problem have QUOTAUGIDLIMIT set, others don't.
2201 probably doesn't have second -level quota, 2202 does - and has a
number of /dev/ploop* devices, but /proc/mounts doesn't list the correct
one.
On Wed, Jan 21, 2015 at 5:51 PM, Kir Kolyshkin <k...@openvz.org> wrote:
>
> On 01/21/2015 08:27 AM, Rene C. wrote:
>
> The reason I became aware of the problem was that a cpanel servers started
> sending this message every morning:
>
> repquota: Can't stat() mounted device /dev/ploop50951p1: No such file or
> directory
>
> All containers on another hardware node and several on this have the
> devices working correctly within the containers.
>
>
> What's the setting of QUOTAUGIDLIMIT for a given container?
> Note ploop device is only created inside the container if second-level
> quota is enabled.
>
>
> On Wed, Jan 21, 2015 at 5:11 PM, Devon B. <devo...@virtualcomplete.com>
> wrote:
>
>> I can't speak as to how to address the issue, but why do you consider it
>> messed up? I logged in to a few nodes and saw the same thing on all of
>> them and I don't remember this being any different in the past. The ploop
>> device only exists outside of the container (when mounted). Inside the
>> container is just a reference, no actual device exists.
>>
>> I don't know enough about the original issue, what are you trying to
>> accomplish with the ploop device inside the container?
>>
>>
>> Rene C. <ope...@dokbua.com>
>> Wednesday, January 21, 2015 6:47 AM
>> I've gone through all containers and actually some of them work
>> correctly, only some are messed up like this.
>>
>> Take for example this one:
>>
>> [root@server22 ~]# vzctl restart 2201
>> Restarting container
>> Stopping container ...
>> Container was stopped
>> Unmounting file system at /vz/root/2201
>> Unmounting device /dev/ploop27939
>> Container is unmounted
>> Starting container...
>> Opening delta /vz/private/2201/root.hdd/root.hdd
>> Adding delta dev=/dev/ploop27939 img=/vz/private/2201/root.hdd/root.hdd
>> (ro)
>> Adding delta dev=/dev/ploop27939
>> img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
>> (rw)
>> Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
>> data='balloon_ino=12,'
>> Container is mounted
>> Adding IP address(es): (redacted)
>> Setting CPU limit: 400
>> Setting CPU units: 50
>> Setting CPUs: 4
>> Container start in progress...
>>
>> So apparently the ploop device should be /dev/ploop/27939. Everything
>> seems to work, inside the container this device is referred by /proc/mounts
>>
>> [root@server22 ~]# vzctl exec 2201 cat /proc/mounts
>> /dev/ploop27939p1 / ext4
>> rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
>> proc /proc proc rw,relatime 0 0
>> sysfs /sys sysfs rw,relatime 0 0
>> none /dev tmpfs rw,relatime,mode=755 0 0
>> none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
>> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
>>
>> But the device is actually missing:
>>
>> [root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
>> ls: /dev/ploop27939p1: No such file or directory
>>
>> In fact, there doesn't seem to be ANY /dev/ploop devices in this
>> container
>>
>> [root@server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
>> ls: /dev/ploop18940: No such file or directory
>> ls: /dev/ploop18940p1: No such file or directory
>> ls: /dev/ploop26517: No such file or directory
>> ls: /dev/ploop26517p1: No such file or directory
>> ls: /dev/ploop27379: No such file or directory
>> ls: /dev/ploop27379p1: No such file or directory
>> ls: /dev/ploop27939: No such file or directory
>> ls: /dev/ploop27939p1: No such file or directory
>> ls: /dev/ploop50951: No such file or directory
>> ls: /dev/ploop50951p1: No such file or directory
>> ls: /dev/ploop52860: No such file or directory
>> ls: /dev/ploop52860p1: No such file or directory
>> ls: /dev/ploop58415: No such file or directory
>> ls: /dev/ploop58415p1: No such file or directory
>>
>> Why does it shows devices when there are none present? Obviously
>> something is messed up, how can we fix this?
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>> Rene C. <ope...@dokbua.com>
>> Tuesday, January 20, 2015 12:04 PM
>>
>> No takers?
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>> Rene C. <ope...@dokbua.com>
>> Tuesday, January 13, 2015 12:00 PM
>> Hm, well I removed the scripts, now I get the error:
>>
>> repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
>> or directory
>>
>> I don't know if this is related at all, it kinda started after a recent
>> update to the latest kernel 2.6.32-042stab102.9
>>
>> Now if I go into any container on this hardware node, the /dev/ploopXXX
>> devices listed in /proc/mount doesn't exist.
>>
>> For example:
>>
>> root@vps2202 [~]# cat /proc/mounts
>> /dev/ploop50951p1 / ext4
>> rw,relatime,barrier=1,stripe=256,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
>> 0 0
>> /dev/simfs /backup simfs rw,relatime 0 0
>> proc /proc proc rw,relatime 0 0
>> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
>> sysfs /sys sysfs rw,relatime 0 0
>> none /dev tmpfs rw,relatime,size=7992992k,nr_inodes=1998248 0 0
>> none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
>> root@vps2202 [~]# ll /dev/ploop50951p1
>> /bin/ls: /dev/ploop50951p1: No such file or directory
>>
>> There are quite a few /dev/ploop* devices under /dev, but not the one
>> linked in /proc/mounts.
>>
>> This goes for all containers on this hardware node. Other nodes not yet
>> upgraded to the latest kernel do not have this problem.
>>
>> Any ideas?
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>> Kir Kolyshkin <k...@openvz.org>
>> Friday, December 26, 2014 6:31 PM
>>
>>
>>
>> No, the script (and its appropriate symlinks) is (re)created on every
>> start (actually mount)
>> of a simfs-based container. It is a conversion process that should get
>> rid of it, unfortunately
>> vzctl doesn't do it currently, so has to be done manually. Feel free to
>> file a bug for vzctl.
>>
>> Kir.
>>
>> _______________________________________________
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>> Scott Dowdle <dow...@montanalinux.org>
>> Friday, December 26, 2014 12:46 PM
>> Greetings,
>>
>> ----- Original Message -----
>>
>> What I understood Kir to say was that the script was created as part of
>> the conversion process and should have been automatically removed (like it
>> was automaically created) after the conversion was complete. Why it wasn't
>> removed I don't know... but you can back up the file somewhere else... and
>> remove it... and if you have problems... you could copy it back. I don't
>> think any of that would be necessary but who knows.
>>
>> TYL,
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing
> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
