[Users] simfs with ploop?

Rene C. openvz at dokbua.com
Thu Dec 4 14:22:06 PST 2014


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20141204/14aa492d/attachment.html>


More information about the Users mailing list