Article ID: 124872, created on Mar 15, 2015, last review on Mar 15, 2015

  • Applies to:
  • Virtuozzo
  • Virtuozzo containers for Linux


After Hardware Node's unexpected shutdown big container starts for a long time, seems like stuck:

Starting the Container ...
Removing the stale lock file /vz/lock/1000.lck
Starting the Container ...
vzquota : (warning) Incorrect quota shutdown for id 1000, recalculating disk usage


Quota detected unclean shutdown, and to avoid inconsistencies triggers quota recalculation. It takes some of time to recalculate quota for the container, time required for this operation depends on container's size and filesystem structure.


In order to understand whether process is stuck or not it is necessary to examine behavior of a vzquota process running for the container in question:

  1. Define CTID variable with the container ID

    # CTID=1000

    Note!: Replace 1000 with your container ID

  2. Find vzquota process which is initializing quota for container in question:

    # ps aux | grep "vzquota init $CTID "| grep -v grep
    root     42323 26.0  0.0  13032  1368 pts/24   D+   18:41   0:00 /usr/sbin/vzquota init 1000 -s 0 -R -p /vz/private/1000/fs -b 2097152 -B 2306048 -i 200000 -I 220000 -e 0 -n 0
  3. Monitor through /proc/ partition files accessed by the vzquota process:

    # while :; do ls -la /proc/`ps aux | grep "vzquota init $CTID "| grep -v grep|awk '{print $2}'`/fd | grep vz; echo ----------------------; sleep 1;done
    lrwx------ 1 root root 64 Mar 15 18:42 4 -> /vz/private/1000/quota.fs
    lr-x------ 1 root root 64 Mar 15 18:42 6 -> /vz/private/1000/fs/root/usr/lib/i386-linux-gnu
    lrwx------ 1 root root 64 Mar 15 18:42 4 -> /vz/private/1000/quota.fs
    lr-x------ 1 root root 64 Mar 15 18:42 6 -> /vz/private/1000/fs/root/usr/local/sb/htdocs/templates/generic/presets_default/electrician
    lrwx------ 1 root root 64 Mar 15 18:42 4 -> /vz/private/1000/quota.fs
    lr-x------ 1 root root 64 Mar 15 18:42 6 -> /vz/private/1000/fs/root/usr/share/man/man1
    lr-x------ 1 root root 64 Mar 15 18:42 7 -> /vz/private/1000/fs/root/usr/share/man/man1/speed.1ssl.gz

If list of open file descriptors is actively changing that means vzquota recalculation is in process and is not stuck - in that case there is no need to do anything, just wait for process to complete.

If process is accessing the same file for a long time period, unable to complete, it might indicate possible issues with the filesystem - try to access the file manually to check if it is accessible overall, or not. If file is not accessible - proceed checking the issue from filesystem aspect. If file is accessible - vzquota process might be having problems to get an exclusive lock for the file - this issue might take place if /vz/ is an NFS share.

In case file is accessible, but vzquota is stuck, it's possible to re-initiate the quota initialization process:

  1. Kill the vzquota process

    # kill -9 42323

    Note!: replace 42323 with a PID obtained in thevious instructions on step 2

  2. Drop quota for container in question

    # vzquota drop 1000
  3. Start container again

    # vzctl start 1000


If there is no time to wait for quota recalculation and container should be started right away by any means possible it is possible to disable disk quota for the container:

Note!: Software sensitive to user/group quota might stop working with this configuration. Also, container will become unlimited in terms of diskspace.

  1. Open container's configuration file with text editor of your choice:

    # vim /etc/vz/conf/1000.conf
  2. Add following line (or edit, if it already exists):

  3. Start container:

    # vzctl start 1000

In order to revert the changes (enable quota back), just roll back the changes:

  1. Stop container

    # vzctl stop 1000
  2. Delete DISK_QUOTA line from the configuration file

  3. Start container

    # vzctl start 1000

Search Words

Incorrect quota shutdown

recalculating disk usage

Incorrect quota shutdown for id , recalculating disk usage

d02f9caf3e11b191a38179103495106f 2897d76d56d2010f4e3a28f864d69223 e8e50b42231236b82df27684e7ec0beb 0dd5b9380c7d4884d77587f3eb0fa8ef

Email subscription for changes to this article
Save as PDF