[Users] simfs with ploop?
Rene C.
openvz at dokbua.com
Fri Dec 5 00:20:44 PST 2014
I'm not sure what you mean by that - do you mean the convert command should
remove it? I don't think it does! What is the best / most correct way to
remove it? rpm -qf report the script isn't owned by any rpm so simply "rm
-f /vz/root/*/etc/*/*/*vzquota*" ? Should I create a bug report for this?
On Fri, Dec 5, 2014 at 1:36 AM, Kir Kolyshkin <kir at openvz.org> wrote:
> 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. <openvz at dokbua.com> 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. <openvz at dokbua.com> 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. <openvz at dokbua.com> 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 <kir at openvz.org> 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 <kir at openvz.org>
>>> 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. <openvz at dokbua.com>
>>> 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 <kir at openvz.org>
>>> 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
>>> >>>>>>> Users at openvz.org
>>> >>>>>>> https://lists.openvz.org/mailman/listinfo/users
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Users mailing list
>>> >>>>> Users at openvz.org
>>> >>>>> https://lists.openvz.org/mailman/listinfo/users
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Users mailing list
>>> >>>> Users at openvz.org
>>> >>>> https://lists.openvz.org/mailman/listinfo/users
>>> >>>
>>> >>> _______________________________________________
>>> >>> Users mailing list
>>> >>> Users at openvz.org
>>> >>> https://lists.openvz.org/mailman/listinfo/users
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Users mailing list
>>> >> Users at openvz.org
>>> >> https://lists.openvz.org/mailman/listinfo/users
>>>
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20141205/869416e7/attachment.html>
More information about the Users
mailing list