I'm still waiting to hear what is the PROPER way of discarding this
script.  Just deleting the base file will cause a large number of symlinks
to become orphans.

rpm reports that the script isn't owned by any package -

# rpm -qf /etc/rc.d/init.d/vzquota
file /etc/rc.d/init.d/vzquota is not owned by any package

- so how did it get installed in the first place?  If I understand you
right it might be created by vzctl? Is there a command in vzctl to remove
it? Should "vzctl convert --layout ploop" not automatically remove it? If
it doesn't, is that a bug that should be reported somewhere?





On Fri, Dec 5, 2014 at 1:36 AM, Kir Kolyshkin <k...@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. <ope...@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. <ope...@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. <ope...@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 <k...@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 <k...@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. <ope...@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 <k...@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@openvz.org
>>> >>>>>>> https://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
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>>
>>
>>
>
>
> _______________________________________________
> 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

Reply via email to