Debian Squeeze (full updates) running on OpenVZ (using Proxmox) with 2.6.32-6-pve kernel. zabbix-agent installed using apt

Hi Joel. From which source you installed them via apt? Point please also on OpenVZ host OS, do you updated recently OpenVZ kernel or tools (If yes - from which kernel/tools version)? Thx in advances.

This issue came up on IRC today with 1.8.8. The person said the host in question was a Linux guest on a KVM server. The other guests however did not have an issue.

To help track down issues like this in the future I would suggest adding a debug level statement to the process function. Specifically within the section where the command get's executed (lines 440-482 in src/libx/zbxsysinfo/sysinfo.c on 1.8.8). Presently there is no way to see what values are returned from the various functions before they are converted to/from text for sending to the Zabbix server, only the result after the text conversion. Adding a debug level statement in here may help to debug future issues which are similarly difficult to track down.

Here is my /etc/apt/sources.list:

deb http://ftp.debian.org/debian squeeze main contrib

deb http://ftp.debian.org/debian squeeze-updates main contrib

deb http://security.debian.org squeeze/updates main contrib

The last time I updated vzctl/vzdump was Sept 30, 2 weeks before problems showed up. Same with the kernel - old version was pve-kernel-2.6.32-4-pve_2.6.32-33_amd64.deb, current version is pve-kernel-2.6.32-6-pve_2.6.32-43_amd64.deb

Joel, can you follow nelsonlab advices and add debug level also in zabbix_agent.conf?

Just wish to point out that increasing DebugLevel to 4 is unlikely to help. The function for obtaining "system.uptime" on Linux boils down to a single system call: sysinfo(&info). The value returned by that system call in info.uptime is then propagated unchanged (at least that is how it should be) to higher levels. What we could do is prepare a patched version of the agent for you that provides more information about that system call and its returned value.

Never mind. I just ran an strace on the program; turns out sysinfo is returning an uptime of 0 as well as loads of

. Totally not your guys' code at all.

Thanks for the help. Should I update this thread if I get a solution from the OpenVZ guys?

thanks, closing. any additional information might help somebody else, so you are welcome to add it

While the problem is indeed located at the OpenVZ kernel at this point (bugreport: http://bugzilla.openvz.org/show_bug.cgi?id=2051), it may be worthwhile implementing the uptime to come from /proc/uptime?
I'm no C developer by heart, but either seems to work fine.