ZABBIX BUGS AND ISSUES

Zabbix agent 1.8.2 returning system uptime of 0

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Agent (G)
  • Labels:
  • Environment:
    Debian Squeeze (full updates) running on OpenVZ (using Proxmox) with 2.6.32-6-pve kernel. zabbix-agent installed using apt
  • Zabbix ID:
    Reviewed 2.0

Description

Ever since I rebooted my system a week ago both of my OpenVZ VMs are reporting a constant system.uptime of 0, even when they have been running for 5+ days. Have tried rebooting both the agent and the VM. Cannot reboot the physical box as there are other critical services running on it. Using zabbix_get from the site's proxy reports a system.uptime of 0 but other values are working correctly. Running 'uptime' from the command prompt gives me the correct output. I don't understand why it stopped working. Please help.

Activity

Hide
Viktors Kohanovskis added a comment - - edited

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.

Show
Viktors Kohanovskis added a comment - - edited 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.
Hide
nelsonab added a comment -

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.

Show
nelsonab added a comment - 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.
Hide
Joel added a comment -

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

Show
Joel added a comment - 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
Hide
Viktors Kohanovskis added a comment -

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

Show
Viktors Kohanovskis added a comment - Joel, can you follow nelsonlab advices and add debug level also in zabbix_agent.conf?
Hide
Aleksandrs Saveljevs added a comment -

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.

Show
Aleksandrs Saveljevs added a comment - 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.
Hide
Joel added a comment -

Never mind. I just ran an strace on the program; turns out sysinfo is returning an uptime of 0 as well as loads of {0, 0, 0}. 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?

Show
Joel added a comment - Never mind. I just ran an strace on the program; turns out sysinfo is returning an uptime of 0 as well as loads of {0, 0, 0}. 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?
Hide
richlv added a comment -

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

Show
richlv added a comment - thanks, closing. any additional information might help somebody else, so you are welcome to add it
Hide
Mattias Geniar added a comment -

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.

Show
Mattias Geniar added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Joel
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: