Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an openvz container that is NOT stopping with the standard vz tools. How can I kill it? I tried a VZ destory but that wont work.


share|improve this question
How was the unstoppable state reached? – Aleksandr Levchuk Oct 6 '11 at 12:17
I'm not really sure. It's a server with multiple containers. One has something in the D state. – Squidly Oct 6 '11 at 12:21
The solution ended up having to reboot the host server to force the container off. – Squidly Oct 11 '11 at 16:31
Stop an unstoppable container? Kind of like immovable object versus unstoppable force? – pauska Nov 24 '11 at 21:52

Well there is a very tricky part... You have to sort out the init process of the VPS, and kill it, see: But... In my opinion you just have one option and that is to restart the HN.

If a VPS get's froozen; look in your syslog if there are any kernel oops, most likely they cause the processes that 'hang'. Furthermore look at the user_beancounters of that particular VPS. Sometime it hangs when installing/upgrading software and if the VPS is not a production one, leave it. It will sort itself in time.

share|improve this answer

Standard way for solving issue like this is this:

  1. Find all container processes using command like this:
  2. Kill all container processes manually using kill -9
  3. If some process can't be killed, check dmesg about hardware errors (in most cases it related with disk or another I/O errors)
  4. Get strace -f -p PID/lsof -p and ps aux|grep PID for this process and send it to but it's bug
  5. Upgrade to latest OpenVZ kernel and userspace because many bugs with similar effect was fixed.
  6. Reboot server using shutdown -r now
share|improve this answer

standard vz lists

— What is that? Did you mean "standard vz tools" or what?

Try (and show me with some pastebin service) vzctl exec VE_NUM ps axf to see what processes are running there and what are theirs states. I had similar problems with OpenVZ on Debian, but I need to be sure that's exactly what I have had.

I assume you know that VE-stopping is made with vzctl stop ;-)

share|improve this answer
Yea I'm aware of the vzctl stop. That does not stop the container. – Squidly Oct 5 '11 at 13:57

It's a little harsh, but the best way I've found to stop a stubborn container is to forcefully kill the container's processes. Command vzpid with grep makes it easy to find:

ps ax | awk '{print $1}' | xargs vzpid | grep <container ID> | awk '{print $1}' | xargs kill -9

Now when you run a vzlist -a it should show the container as "stopped". Better than rebooting the HN imo.

share|improve this answer
vzctl chkpnt CTID --kill

share|improve this answer
This needs more explanation to be a full answer. – Sven Oct 1 '15 at 16:44

Its (most of the time) as simple as that:

vzctl stop [CTID]

if any problems occure go to the lock files (at my install /vz/lock) and rename / delete the lock file named [CTID].lck

vzctl start [CTID]

Voila, you are done.

share|improve this answer
The user has already said that this did not work. – Michael Hampton May 28 '14 at 12:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.