[Users] simfs with ploop?
Kir Kolyshkin
kir at openvz.org
Thu Dec 4 16:36:09 PST 2014
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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Users at openvz.org>
> >>>>>>> https://lists.openvz.org/mailman/listinfo/users
> >>>>>
> >>>>> _______________________________________________
> >>>>> Users mailing list
> >>>>> Users at openvz.org <mailto:Users at openvz.org>
> >>>>> https://lists.openvz.org/mailman/listinfo/users
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at openvz.org <mailto:Users at openvz.org>
> >>>> https://lists.openvz.org/mailman/listinfo/users
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at openvz.org <mailto:Users at openvz.org>
> >>> https://lists.openvz.org/mailman/listinfo/users
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at openvz.org <mailto: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/0eef6b5b/attachment-0001.html>
More information about the Users
mailing list