Home » Mailing lists » Users » VE fails to stop
VE fails to stop [message #24812] |
Tue, 11 December 2007 01:20 ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
Cliff Wells
Messages: 30 Registered: June 2006
|
Member |
|
|
Hardware: dual Opteron 242
Kernel: linux-2.6.18-openvz-028.049
Host OS: Gentoo
Guest OS: ubuntu-7.10-i386-minimal
Both host and VE are fresh installs.
I noticed that "vzctl stop 101" would fail with
Stopping VPS ...
Unable to stop VPS, operation timed out
This of course also prevented me from properly shutting down the system
(power off required).
I found a post [1] that seemed related, which led to investigating halt
commands:
vps1 ~ # vzctl enter 101
root@localhost:/# halt -p
shutdown: Unable to send message: Connection refused
root@localhost:/# halt
shutdown: Unable to send message: Connection refused
root@localhost:/dev# halt -fp
got signal 9
exited from VE 101
vps1 ~ #
Does this appear to be a problem with OVZ or with the guest template?
[1] http://forum.openvz.org/index.php?t=msg&goto=6354&
|
|
|
|
|
|
Re: VE fails to stop [message #24873 is a reply to message #24812] |
Tue, 11 December 2007 16:35 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
This is probably a problem with VE start, not stop. VE started badly and
can not stop.
This is known issue (a bad interaction of Ubuntu's upstart (init
replacement) and vzctl) which is fixed in upcoming vzctl release, see
http://bugzilla.openvz.org/662
Now you have three options:
1. Wait for next vzctl release (should happen real soon now).
2. Replace upstart with init (sysvinit) inside a VE
3. Rebuild vzctl either from GIT or just adding the patch from git
linked from bug #622.
Cliff Wells wrote:
> Hardware: dual Opteron 242
> Kernel: linux-2.6.18-openvz-028.049
> Host OS: Gentoo
> Guest OS: ubuntu-7.10-i386-minimal
>
> Both host and VE are fresh installs.
>
> I noticed that "vzctl stop 101" would fail with
>
> Stopping VPS ...
> Unable to stop VPS, operation timed out
>
>
> This of course also prevented me from properly shutting down the system
> (power off required).
>
> I found a post [1] that seemed related, which led to investigating halt
> commands:
>
> vps1 ~ # vzctl enter 101
> root@localhost:/# halt -p
> shutdown: Unable to send message: Connection refused
> root@localhost:/# halt
> shutdown: Unable to send message: Connection refused
> root@localhost:/dev# halt -fp
> got signal 9
> exited from VE 101
> vps1 ~ #
>
>
> Does this appear to be a problem with OVZ or with the guest template?
>
>
>
> [1] http://forum.openvz.org/index.php?t=msg&goto=6354&
>
>
>
|
|
|
|
Re: VE fails to stop [message #24919 is a reply to message #24873] |
Wed, 12 December 2007 07:10 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
Cliff Wells
Messages: 30 Registered: June 2006
|
Member |
|
|
On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
> This is probably a problem with VE start, not stop. VE started badly and
> can not stop.
>
> This is known issue (a bad interaction of Ubuntu's upstart (init
> replacement) and vzctl) which is fixed in upcoming vzctl release, see
> http://bugzilla.openvz.org/662
>
> Now you have three options:
> 1. Wait for next vzctl release (should happen real soon now).
> 2. Replace upstart with init (sysvinit) inside a VE
> 3. Rebuild vzctl either from GIT or just adding the patch from git
> linked from bug #622.
I installed vzctl from git. This seems to solve the problem with the VE
starting and stopping. However, after the VE is run once, the network
refuses to come up unless I delete the VE's IP address and add it again:
vps1 ~ # vzctl start 106
Starting VE ...
VE is mounted
Adding IP address(es): 10.10.10.106
Setting CPU units: 1584
Configure meminfo: 72498
Set hostname: vz106
File resolv.conf was modified
VE start in progress...
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
noqueue
link/void
inet 127.0.0.1/32 scope host venet0
inet 10.10.10.106/32 scope global venet0:0
root@vz106:/# ping google.com
PING google.com (72.14.207.99) 56(84) bytes of data.
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
time=98.8 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
time=99.1 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
time=98.1 ms
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
root@vz106:/# logout
exited from VE 106
vps1 ~ # vzctl stop 106
Stopping VE ...
VE was stopped
VE is unmounted
vps1 ~ # vzctl start 106
Starting VE ...
VE is mounted
Adding IP address(es): 10.10.10.106
Setting CPU units: 1584
Configure meminfo: 72498
Set hostname: vz106
File resolv.conf was modified
VE start in progress...
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ping google.com
ping: unknown host google.com
root@vz106:/# ip addr
1: lo: <LOOPBACK> mtu 16436 qdisc noop
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop
link/void
root@vz106:/#
If I exit the VE and delete/re-add the IP address it starts working
again:
vps1 ~ # vzctl set 106 --ipdel all --save
Deleting IP address(es):
Adding IP address(es):
Saved parameters for VE 106
vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
Adding IP address(es): 10.10.10.106
Saved parameters for VE 106
vps1 ~ # vzctl enter 106
entered into VE 106
id: cannot find name for group ID 11
root@vz106:/# ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
time=76.8 ms
Could this be another problem with upstart?
The five CentOS 5 VE's I setup prior to this work perfectly.
It's also worth noting I'm using 2.6.22 ovz005.
Regards,
Cliff
|
|
|
|
|
|
|
|
Re: VE fails to stop [message #24970 is a reply to message #24919] |
Wed, 12 December 2007 15:33 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Cliff Wells wrote:
> On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
>
>> This is probably a problem with VE start, not stop. VE started badly and
>> can not stop.
>>
>> This is known issue (a bad interaction of Ubuntu's upstart (init
>> replacement) and vzctl) which is fixed in upcoming vzctl release, see
>> http://bugzilla.openvz.org/662
>>
>> Now you have three options:
>> 1. Wait for next vzctl release (should happen real soon now).
>> 2. Replace upstart with init (sysvinit) inside a VE
>> 3. Rebuild vzctl either from GIT or just adding the patch from git
>> linked from bug #622.
>>
>
> I installed vzctl from git. This seems to solve the problem with the VE
> starting and stopping. However, after the VE is run once, the network
> refuses to come up unless I delete the VE's IP address and add it again:
>
>
> vps1 ~ # vzctl start 106
> Starting VE ...
> VE is mounted
> Adding IP address(es): 10.10.10.106
> Setting CPU units: 1584
> Configure meminfo: 72498
> Set hostname: vz106
> File resolv.conf was modified
> VE start in progress...
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ip addr
> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
> noqueue
> link/void
> inet 127.0.0.1/32 scope host venet0
> inet 10.10.10.106/32 scope global venet0:0
> root@vz106:/# ping google.com
> PING google.com (72.14.207.99) 56(84) bytes of data.
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
> time=98.8 ms
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
> time=99.1 ms
> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
> time=98.1 ms
>
> --- google.com ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
> rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
> root@vz106:/# logout
> exited from VE 106
> vps1 ~ # vzctl stop 106
> Stopping VE ...
> VE was stopped
> VE is unmounted
> vps1 ~ # vzctl start 106
> Starting VE ...
> VE is mounted
> Adding IP address(es): 10.10.10.106
> Setting CPU units: 1584
> Configure meminfo: 72498
> Set hostname: vz106
> File resolv.conf was modified
> VE start in progress...
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ping google.com
> ping: unknown host google.com
> root@vz106:/# ip addr
> 1: lo: <LOOPBACK> mtu 16436 qdisc noop
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop
> link/void
> root@vz106:/#
>
> If I exit the VE and delete/re-add the IP address it starts working
> again:
>
> vps1 ~ # vzctl set 106 --ipdel all --save
> Deleting IP address(es):
> Adding IP address(es):
> Saved parameters for VE 106
> vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
> Adding IP address(es): 10.10.10.106
> Saved parameters for VE 106
> vps1 ~ # vzctl enter 106
> entered into VE 106
> id: cannot find name for group ID 11
> root@vz106:/# ping google.com
> PING google.com (64.233.187.99) 56(84) bytes of data.
> 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
> time=76.8 ms
>
>
>
> Could this be another problem with upstart?
>
I am investigating the problem right now, will keep you updated.
|
|
|
Re: VE fails to stop [message #25045 is a reply to message #24970] |
Thu, 13 December 2007 16:02 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
0. (just repeating) Ubuntu-7.10 template with upstart instead of init
requires vzctl > 3.0.18. An updated vzctl (apparently it will have
version of 3.0.21) is not yet released.
1. There was an obscure bug in not-yet-released vzctl, which fires when
a Debian/Ubuntu based VE has more than one IP address. The bug is now
fixed in GIT (see http://tinyurl.com/2w68ch) and will be included into
next vzctl release. Note that released vzctl version (i.e. 3.0.18) is
not affected.
2. Ubuntu 7.10 initscripts (including netscripts) relied on the fact
that /var/run is resides on a tmpfs partition, so it would be empty
after reboot. Because of that they don't care about stopping some
services, cleaning state files etc. It only became a problem when I
optimized Ubuntu template to not use tmpfs (because tmpfs eats some
physical memory, which might not be desired then there are a lot of VEs
on a system). Networking was not up on VE restart just because of that
-- ifup script saved interface state in /var/run/network/ifstate, while
ifdown was never called on VE stop, so next ifup (after VE reboot) was
not taking care of interfaces which according to ifstate were already up.
This was fixed in an updated ubuntu templates that I just uploaded to
http://download.openvz.org/template/precreated/. These templates are now
back to using tmpfs for some directories. Other changes I made are:
removal of a few more packages (ntpdate eject libasound2 pciutils
tasksel tasksel-data laptop-detect), log files cleanup.
Also, while at it, I have modified Ubuntu Gutsy template creation
document in wiki.
Latest version: http://wiki.openvz.org/Ubuntu_Gutsy_template_creation
My changes: http://tinyurl.com/2u2oxj
Hope that helps.
PS I appreciate if somebody can help with testing a new vzctl from git.
**
Kir Kolyshkin wrote:
> Cliff Wells wrote:
>> On Tue, 2007-12-11 at 19:35 +0300, Kir Kolyshkin wrote:
>>
>>> This is probably a problem with VE start, not stop. VE started badly
>>> and can not stop.
>>>
>>> This is known issue (a bad interaction of Ubuntu's upstart (init
>>> replacement) and vzctl) which is fixed in upcoming vzctl release,
>>> see http://bugzilla.openvz.org/662
>>>
>>> Now you have three options:
>>> 1. Wait for next vzctl release (should happen real soon now).
>>> 2. Replace upstart with init (sysvinit) inside a VE
>>> 3. Rebuild vzctl either from GIT or just adding the patch from git
>>> linked from bug #622.
>>>
>>
>> I installed vzctl from git. This seems to solve the problem with the VE
>> starting and stopping. However, after the VE is run once, the network
>> refuses to come up unless I delete the VE's IP address and add it again:
>>
>>
>> vps1 ~ # vzctl start 106
>> Starting VE ...
>> VE is mounted
>> Adding IP address(es): 10.10.10.106
>> Setting CPU units: 1584
>> Configure meminfo: 72498
>> Set hostname: vz106
>> File resolv.conf was modified
>> VE start in progress...
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ip addr
>> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback
>> 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 scope host lo
>> inet6 ::1/128 scope host valid_lft forever preferred_lft
>> forever
>> 3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc
>> noqueue link/void inet 127.0.0.1/32 scope host venet0
>> inet 10.10.10.106/32 scope global venet0:0
>> root@vz106:/# ping google.com
>> PING google.com (72.14.207.99) 56(84) bytes of data.
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=238
>> time=98.8 ms
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=238
>> time=99.1 ms
>> 64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=238
>> time=98.1 ms
>>
>> --- google.com ping statistics ---
>> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
>> rtt min/avg/max/mdev = 98.106/98.696/99.138/0.504 ms
>> root@vz106:/# logout
>> exited from VE 106
>> vps1 ~ # vzctl stop 106
>> Stopping VE ...
>> VE was stopped
>> VE is unmounted
>> vps1 ~ # vzctl start 106
>> Starting VE ...
>> VE is mounted
>> Adding IP address(es): 10.10.10.106
>> Setting CPU units: 1584
>> Configure meminfo: 72498
>> Set hostname: vz106
>> File resolv.conf was modified
>> VE start in progress...
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ping google.com
>> ping: unknown host google.com
>> root@vz106:/# ip addr
>> 1: lo: <LOOPBACK> mtu 16436 qdisc noop link/loopback
>> 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 3: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop
>> link/void root@vz106:/#
>> If I exit the VE and delete/re-add the IP address it starts working
>> again:
>>
>> vps1 ~ # vzctl set 106 --ipdel all --save
>> Deleting IP address(es): Adding IP address(es): Saved parameters for
>> VE 106
>> vps1 ~ # vzctl set 106 --ipadd 10.10.10.106 --save
>> Adding IP address(es): 10.10.10.106
>> Saved parameters for VE 106
>> vps1 ~ # vzctl enter 106
>> entered into VE 106
>> id: cannot find name for group ID 11
>> root@vz106:/# ping google.com
>> PING google.com (64.233.187.99) 56(84) bytes of data.
>> 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=237
>> time=76.8 ms
>>
>>
>>
>> Could this be another problem with upstart?
>>
>
> I am investigating the problem right now, will keep you updated.
|
|
|
|
Re: VE fails to stop [message #25069 is a reply to message #25045] |
Thu, 13 December 2007 23:23 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
Cliff Wells
Messages: 30 Registered: June 2006
|
Member |
|
|
On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
Seems to work fine. Minor nit would be the unknown group 11. I did a
'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
but chowning them to root didn't get rid of the message.
Networking now seems to work fine.
I was a bit curious about the results of 'mount':
vps1 ~ # vzctl enter 108
entered into VE 108
id: cannot find name for group ID 11
root@vz108:/# mount
simfs on / type simfs (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
root@vz108:/#
It looks as if perhaps the tmpfs's are being mounted twice now?
Overall this is much better than it was before.
Regards,
Cliff
|
|
|
Re: VE fails to stop [message #25084 is a reply to message #25069] |
Fri, 14 December 2007 09:35 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Cliff Wells wrote:
> On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
>
>> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
>>
>
> Seems to work fine. Minor nit would be the unknown group 11. I did a
> 'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
> but chowning them to root didn't get rid of the message.
>
This message ("id: cannot find name for group ID 11") comes from id
binary which is executed from /etc/profile during user login (or vzctl
enter). Since root belongs to group 11, "id" tries to get the name of
the group.
The line about group with ID of 11 is absent from /etc/group. I'm not
sure why. Since you found out some /dev/fd* files belong to the group, I
guess group name should be something like 'floppy'. I guess that adding
something like
floppy:x:11:
to /etc/group should fix the issue.
I will file a bug to ubuntu about that, but generally it should be
harmless as it is.
> Networking now seems to work fine.
>
> I was a bit curious about the results of 'mount':
>
> vps1 ~ # vzctl enter 108
> entered into VE 108
> id: cannot find name for group ID 11
> root@vz108:/# mount
> simfs on / type simfs (rw,noatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec)
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /dev/shm type tmpfs (rw)
> devpts on /dev/pts type devpts (rw)
> tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec)
> tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec)
> root@vz108:/#
>
> It looks as if perhaps the tmpfs's are being mounted twice now?
>
Yep, first time they do it in /etc/init.d/mountkernfs.sh, then in
/etc/init.d/mountall.sh (calling pre_mountall function from sourced
/lib/init/mount-functions.sh) they bind-mount both /var/run and
/var/lock to under /dev/shm. That is why we see what we see.
I am not touching that stuff now because I already learned they assume a
lot of things (like /var/run is clean after reboot) and one can open a
can of worms breaking their assumptions.
Still I don't understand why they mount twice and I will file a bug
about it.
> Overall this is much better than it was before.
>
Hope so :)
|
|
|
Re: VE fails to stop [message #25100 is a reply to message #25084] |
Fri, 14 December 2007 12:59 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Kir Kolyshkin wrote:
> Cliff Wells wrote:
>> On Thu, 2007-12-13 at 19:02 +0300, Kir Kolyshkin wrote:
>>
>>> OK, here's what I found concerning ubuntu-7.10 VE vs. OpenVZ.
>>>
>>
>> Seems to work fine. Minor nit would be the unknown group 11. I did a
>> 'find -gid 11' and it turned up a bunch of /dev/fd* stuff with that GID,
>> but chowning them to root didn't get rid of the message.
>>
>
> This message ("id: cannot find name for group ID 11") comes from id
> binary which is executed from /etc/profile during user login (or vzctl
> enter). Since root belongs to group 11, "id" tries to get the name of
> the group.
>
> The line about group with ID of 11 is absent from /etc/group. I'm not
> sure why. Since you found out some /dev/fd* files belong to the group,
> I guess group name should be something like 'floppy'. I guess that
> adding something like
> floppy:x:11:
> to /etc/group should fix the issue.
>
> I will file a bug to ubuntu about that, but generally it should be
> harmless as it is.
Well, apparently the problem is way different. They do have floppy
group, but with a different GID. The problem is it looks like MAKEDEV
script used by debootstrap to create devices is using host system's
/etc/groups, thus /dev/fd* has a group ID of 11, which is 'floppy' on my
host Gentoo system I use to bootstrap this template.
So, this looks like a bug in debootstrap.
>
>>
>> It looks as if perhaps the tmpfs's are being mounted twice now?
>>
> Yep, first time they do it in /etc/init.d/mountkernfs.sh, then in
> /etc/init.d/mountall.sh (calling pre_mountall function from sourced
> /lib/init/mount-functions.sh) they bind-mount both /var/run and
> /var/lock to under /dev/shm. That is why we see what we see.
>
> I am not touching that stuff now because I already learned they assume
> a lot of things (like /var/run is clean after reboot) and one can open
> a can of worms breaking their assumptions.
>
> Still I don't understand why they mount twice and I will file a bug
> about it.
Apparently they do want it that way
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/163956
|
|
|
vzctl --cpus causes strange load in top [message #25229 is a reply to message #24926] |
Tue, 18 December 2007 09:14 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
Guido Stepken
Messages: 4 Registered: December 2007
|
Junior Member |
|
|
vzctl –cpus causes strange load metering:
top - 09:40:02 up 9 days, 7:32, 0 users, load average: 864.89, 938.24,
675.41
Tasks: 124 total, 2 running, 121 sleeping, 0 stopped, 1 zombie
Cpu(s): 13.7%us, 0.6%sy, 0.0%ni, 84.6%id, 1.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16099800k total, 15962272k used, 137528k free, 271512k buffers
Swap: 3911816k total, 6920k used, 3904896k free, 11216460k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14004 apache 25 0 14336 10m 9772 R 100 0.1 0:06.79 convert
14015 apache 15 0 6988 3276 1588 S 1 0.0 0:00.04 proftpd
13732 apache 15 0 41744 24m 2840 S 0 0.2 0:06.36 apache2
13826 apache 18 0 41908 24m 2836 S 0 0.2 0:04.76 apache2
13990 root 15 0 2240 1132 836 R 0 0.0 0:00.04 top
1 root 18 0 1596 540 476 S 0 0.0 0:01.84 init
25736 root 18 0 2076 816 504 S 0 0.0 0:05.91 syslog-ng
26150 root 18 0 4096 932 616 S 0 0.0 0:00.00 sshd
28340 mysql 18 0 550m 368m 4152 S 0 2.3 118:43.82 mysqld
32152 ftp 18 0 6192 1380 612 S 0 0.0 0:01.76 proftpd
32246 root 18 0 1652 464 384 S 0 0.0 0:00.23 cron
1515 root 17 0 6360 1668 1256 S 0 0.0 0:07.12 master
1522 postfix 15 0 6404 1712 1284 S 0 0.0 0:04.30 qmgr
17834 root 18 0 1980 668 532 S 0 0.0 0:00.00 vzctl
17835 root 18 0 2736 1516 1236 S 0 0.0 0:00.00 bash
32323 root 18 0 2180 832 664 S 0 0.0 0:00.14 cron
32325 root 18 0 0 0 0 Z 0 0.0 0:00.00 bash <defunct>
1406 root 18 0 1500 288 236 S 0 0.0 0:00.01 cronolog
1423 root 15 0 22932 10m 4020 S 0 0.1 0:00.11 apache2-php5
1424 root 18 0 1640 424 360 S 0 0.0 0:00.00 cronolog
1552 apache 18 0 22932 8060 1820 S 0 0.1 0:00.00 apache2-php5
1553 apache 18 0 22932 8060 1820 S 0 0.1 0:00.00 apache2-php5
3549 root 18 0 6484 1696 1292 S 0 0.0 0:00.00 sendmail
3551 root 25 0 6456 1656 1256 S 0 0.0 0:00.02 postdrop
2018 root 18 0 1508 292 236 S 0 0.0 0:00.00 cronolog
3133 root 18 0 29504 13m 4048 S 0 0.1 0:00.87 apache2
3134 root 18 0 1636 428 360 S 0 0.0 0:00.01 cronolog
3138 root 18 0 1636 428 360 S 0 0.0 0:00.04 cronolog
3139 root 18 0 1644 432 360 S 0 0.0 0:00.00 cronolog
3141 root 18 0 1644 428 360 S 0 0.0 0:00.01 cronolog
3143 root 18 0 1644 428 360 S 0 0.0 0:00.00 cronolog
3145 root 18 0 1636 424 360 S 0 0.0 0:00.00 cronolog
3148 root 18 0 1512 292 236 S 0 0.0 0:00.01 cronolog
3150 root 18 0 1644 428 360 S 0 0.0 0:00.04 cronolog
3151 root 18 0 1508 292 236 S 0 0.0 0:00.00 cronolog
3152 root 18 0 1504 292 236 S 0 0.0 0:00.01 cronolog
3153 root 25 0 1512 296 236 S 0 0.0 0:00.00 cronolog
3154 root 18 0 1632 424 360 S 0 0.0 0:00.37 cronolog
3155 root 18 0 1644 432 360 S 0 0.0 0:00.00 cronolog
3156 root 18 0 1644 432 360 S 0 0.0 0:00.01 cronolog
3157 root 18 0 1632 420 360 S 0 0.0 0:00.01 cronolog
3158 root 18 0 1636 428 360 S 0 0.0 0:00.01 cronolog
ggh1-vps / # cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
501: kmemsize 12957612 23959066 59436509 65380159 0
lockedpages 0 5 2902 2902 0
privvmpages 202365 491934 1200000 1200000 2673511
shmpages 2330 19000 62209 62209 0
dummy 0 0 0 0 0
numproc 127 199 32000 32000 0
physpages 137440 361644 0 2147483647 0
vmguarpages 0 0 622098 2147483647 0
oomguarpages 139149 363498 1000000 2147483647 0
numtcpsock 15 137 2666 2666 0
numflock 2 77 1000 1100 0
numpty 2 3 16 16 0
numsiginfo 0 104 1024 1024 0
tcpsndbuf 2574336 13694864 100000000 100000000 0
tcprcvbuf 2430288 7808832 100000000 100000000 0
othersockbuf 162352 1219296 6000000 15366053 96438
dgramrcvbuf 0 8368 4446117 4446117 0
numothersock 104 128 2666 2666 0
dcachesize 1612456 1791880 12973980 13363200 0
numfile 3471 4270 100000 100000 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 57 57 512 512 0
Have fun, regards, Guido
Keep up the good work!
System: Gentoo + stable openvz kernel -> runs fine so far
|
|
|
|
Re: vzctl --cpus causes strange load in top [message #25234 is a reply to message #25229] |
Tue, 18 December 2007 11:34 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) |
|
stepken wrote:
>
> vzctl –cpus causes strange load metering:
>
> <...skipped...>
> System: Gentoo + stable openvz kernel -> runs fine so far
As Vasily points out, this bug is fixed in 051 kernel. On a Gentoo
system if you want to upgrade to 051, you have to do the following (as
root):
# To enable ebuilds not marked as unstable
echo "sys-kernel/openvz-sources" >> /etc/portage/package.keywords
# To emerge this kernel (they have changed numbering)
emerge --oneshot =sys-kernel/openvz-sources-2.6.18.028.051
|
|
|
Goto Forum:
Current Time: Sun Sep 01 01:58:31 GMT 2024
Total time taken to generate the page: 0.05792 seconds
|