I think the script left after conversion. It is no longer needed,
you can remove it (and as far as I can tell it won't be recreated
by vzctl if ploop is used).
On 12/04/2014 02:22 PM, Rene C. wrote:
It seems /etc/rc.d/init.d/vzquota somehow is responsible for this problem:
# cat -n /etc/rc.d/init.d/vzquota
1 #!/bin/sh
2 # chkconfig: 2345 10 90
3 # description: prepare container to use OpenVZ 2nd-level disk
quotas
4
5 ### BEGIN INIT INFO
6 # Provides: vzquota
7 # Required-Start: $local_fs $time $syslog
8 # Required-Stop: $local_fs
9 # Default-Start: 2 3 4 5
10 # Default-Stop: 0 1 6
11 # Short-Description: Start vzquota at the end of boot
12 # Description: Configure OpenVZ disk quota for a container.
13 ### END INIT INFO
14
15 start() {
16 if [ ! -L /etc/mtab ]; then
17 rm -f /etc/mtab >/dev/null 2>&1
18 ln -sf /proc/mounts /etc/mtab
19 fi
20 dev=$(awk '($2 == "/") && ($4 ~ /usrquota/) && ($4 ~
/grpquota/) {print $1}' /etc/mtab)
21 if test -z "$dev"; then
22 dev="/dev/simfs"
23 rm -f /etc/mtab >/dev/null 2>&1
24 echo "/dev/simfs / reiserfs
rw,usrquota,grpquota 0 0" > /etc/mtab
25 grep -v " / " /proc/mounts >> /etc/mtab
2>/dev/null
26 chmod 644 /etc/mtab
27 fi
28 [ -e "$dev" ] || mknod $dev b 0 60
29 quotaon -aug
30 }
31
32 case "$1" in
33 start)
34 start
35 ;;
36 *)
37 exit
38 esac
So it seems in line 16-19 first the symlink from /proc/mounts to
/etc/mtab is made correctly, but then in line 20 the '/' partition is
checked for keywords /usrquota/ and /grpquota/, and if they're missing
it then overwrites the symlink again. AFAICS this is what is breaking
the symlink.
Whats the problem with this? Should this script be changed for ploop
containers?
On Sun, Nov 30, 2014 at 12:07 PM, Rene C. <[email protected]
<mailto:[email protected]>> wrote:
I've just noticed this happen also in a Plesk container, so it's
not just limited to Cpanel. The date seems to correspond to a
restore that was made so it may be related to the
vzpbackup/vzprestore scripts.
On Sat, Jan 4, 2014 at 8:34 AM, Rene C. <[email protected]
<mailto:[email protected]>> wrote:
Oddly enough this problem has returned - it now shows simfs again.
Nobody has explicitly changed anything. The container runs Cpanel,
could that have messed things up? It actually looks like cpanel
overrides the symlink when they add their jailshell. Have you
noticed
this before?
/proc/mounts looks correct.
On Wed, Dec 18, 2013 at 10:25 AM, Rene C. <[email protected]
<mailto:[email protected]>> wrote:
> Thanks, now I understand.
>
> So after deleting /etc/mtab I need to make as symlink from
> /proc/mounts (ln -s /proc/mounts /etc/mtab). That was the
bit I was
> missing.
>
>
> On Wed, Dec 18, 2013 at 1:36 AM, Kir Kolyshkin
<[email protected] <mailto:[email protected]>> wrote:
>> On 12/17/2013 12:27 AM, Rene C. wrote:
>>>
>>> Sure ....
>>>
>>> # ls -l /vza1/private/1703
>>> total 16
>>> drwxr-xr-x 2 root root 4096 Dec 15 04:10 dump
>>> drwx------ 3 root root 4096 Dec 15 04:10 root.hdd
>>> -rw-r--r-- 1 root root 443 Dec 15 04:09 Snapshots.xml
>>> -rw-r--r-- 1 root root 37 Dec 15 03:06 vzpbackup_snapshot
>>> # vzlist -o layout 1703
>>> LAYOUT
>>> ploop
>>> #
>>>
>>> Surely deleting the mount table isn't healthy, isn't it
needed by
>>> something?
>>
>>
>> This is how it should look like:
>>
>> [host] # vzctl enter 1018
>> entered into CT 1018
>> [CT1018] # ls -l /etc/mtab
>> lrwxrwxrwx 1 root root 12 Nov 7 21:20 /etc/mtab ->
/proc/mounts
>>
>> And /proc/mounts is showing info from the kernel which
can't be wrong:
>>
>> [CT1018]# cat /proc/mounts
>> /dev/ploop51540p1 / 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 devtmpfs rw,relatime,mode=755 0 0
>> none /dev/pts devpts
rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
>> none /dev/shm tmpfs rw,relatime 0 0
>> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
>>
>>
>>>
>>> On Tue, Dec 17, 2013 at 9:41 AM, Kir Kolyshkin
<[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> On 12/16/2013 04:51 PM, Rene C. wrote:
>>>>>
>>>>> I tried just removing it, does not seem to fix anything.
Need to do
>>>>> anything else? Remount, restart, anything?
>>>>
>>>>
>>>> Would be great if you can copy-paste some output from the
terminal,
>>>> otherwise it's more complicated to debug.
>>>>
>>>> Maybe your CT was not really converted.
>>>>
>>>> Please show output of
>>>>
>>>> ls -l /vz/private/1703/
>>>> vzlist -o layout 1703
>>>>
>>>>
>>>> On Thu, Dec 12, 2013 at 11:43 AM, Rene C.
<[email protected] <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Ok thanks. Just remove it, nothing else? Need to
restart the
>>>>>> container or anything?
>>>>>>
>>>>>> On Thu, Dec 12, 2013 at 10:02 AM, Kir Kolyshkin
<[email protected] <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> On 12/11/2013 06:28 PM, Rene C. wrote:
>>>>>>>>
>>>>>>>> I just noticed there is a contaner on one of our
hardware nodes that
>>>>>>>> appears to have been changed to ploop, but the
filesystem is still
>>>>>>>> simfs:
>>>>>>>>
>>>>>>>> # vzctl exec 1703 df -h
>>>>>>>> Filesystem Size Used Avail Use% Mounted on
>>>>>>>> /dev/simfs 99G 65G 29G 70% /
>>>>>>>> none 1.0G 4.0K 1.0G 1% /dev
>>>>>>>> # vzctl convert 1703
>>>>>>>> CT is already on ploop
>>>>>>>>
>>>>>>>>
>>>>>>>> All other containers use a /dev/ploopXXXX device.
>>>>>>>>
>>>>>>>> Is this a problem? Should it be fixed? How?
>>>>>>>
>>>>>>>
>>>>>>> I guess this is caused by a record in CT's /etc/mtab.
This should be
>>>>>>> harmful.
>>>>>>> If you want to fix it, just remove CT's /etc/mtab
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> https://lists.openvz.org/mailman/listinfo/users
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://lists.openvz.org/mailman/listinfo/users
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/users
