ZABBIX BUGS AND ISSUES

proc.num show incorrect data under FreeBSD

Details

  • Zabbix ID:
    Reviewed 2.0

Description

proc.num show incorrect data under FreeBSD. Example:

ps ax|wc -l
59

zabbix_agentd -t proc.num[]
proc.num[] [u|127]
  1. proc.c.patch
    2012 Mar 28 19:45
    1.0 kB
    Jim Riggs
  2. proc.c+vsz.patch
    2012 Apr 26 06:07
    2 kB
    Jim Riggs

Issue Links

Activity

Hide
Oleksiy Zagorskyi added a comment -

Several users can confirm the same: http://www.zabbix.com/forum/showthread.php?t=22322
I'm too.

Show
Oleksiy Zagorskyi added a comment - Several users can confirm the same: http://www.zabbix.com/forum/showthread.php?t=22322 I'm too.
Hide
Alexander Vladishev added a comment -

Confirmed in version pre1.8.6, r20279.

Show
Alexander Vladishev added a comment - Confirmed in version pre1.8.6, r20279.
Alexander Vladishev made changes -
Field Original Value New Value
Status Open [ 1 ] Confirmed [ 10000 ]
Alexei Vladishev made changes -
Labels freebsd
Fix Version/s 2.0 [ 10402 ]
Priority Trivial [ 5 ] Major [ 3 ]
Zabbix ID NA Reviewed 2.0
Hide
Ya Bo added a comment -

FreeBSD 9.0, zabbix-agent-1.8.10,2

zabbix-1.8.10/src/libs/zbxsysinfo/freebsd/proc.c
#if(__FreeBSD_version > 500000)
if (proc[i].ki_flag & P_KTHREAD) /* skip a system thread */
continue;
#endif

не работает, в результате имеем +системные треды

Show
Ya Bo added a comment - FreeBSD 9.0, zabbix-agent-1.8.10,2 zabbix-1.8.10/src/libs/zbxsysinfo/freebsd/proc.c #if(__FreeBSD_version > 500000) if (proc[i].ki_flag & P_KTHREAD) /* skip a system thread */ continue; #endif не работает, в результате имеем +системные треды
Hide
Oleksiy Zagorskyi added a comment -

related issue ZBX-4704

Show
Oleksiy Zagorskyi added a comment - related issue ZBX-4704
Hide
Jim Riggs added a comment -

Please try the attached patch. It correctly calls sysctl() for proc.num and proc.mem with KERN_PROC_PROC instead of KERN_PROC_ALL for FreeBSD 5 and later. (Is this check really necessary anymore? Is < v5 supported?)

This has fixed the issue in my environment.

Show
Jim Riggs added a comment - Please try the attached patch. It correctly calls sysctl() for proc.num and proc.mem with KERN_PROC_PROC instead of KERN_PROC_ALL for FreeBSD 5 and later. (Is this check really necessary anymore? Is < v5 supported?) This has fixed the issue in my environment.
Jim Riggs made changes -
Attachment proc.c.patch [ 18455 ]
Hide
Ya Bo added a comment - - edited

FreeBSD 8.3-PRERELEASE
zabbix-agent-1.8.10_1,2

confirm, patch is good

Show
Ya Bo added a comment - - edited FreeBSD 8.3-PRERELEASE zabbix-agent-1.8.10_1,2 confirm, patch is good
Hide
Pavel Timofeev added a comment -

thanks to Jim! proc.num work on FreeBSD 9.0-RELEASE amd64.

But I can't decide about proc.mem. Which unit does proc.mem return? Kbytes, bytes, etc.? Documentation didn't help=(

Show
Pavel Timofeev added a comment - thanks to Jim! proc.num work on FreeBSD 9.0-RELEASE amd64. But I can't decide about proc.mem. Which unit does proc.mem return? Kbytes, bytes, etc.? Documentation didn't help=(
richlv made changes -
Link This issue is duplicated by ZBX-4704 [ ZBX-4704 ]
Hide
richlv added a comment -

regarding documentation, could you please open another issue (documentation component) ?
thanks

Show
richlv added a comment - regarding documentation, could you please open another issue (documentation component) ? thanks
Hide
Pavel Timofeev added a comment -
Show
Pavel Timofeev added a comment - 2 richlv: https://support.zabbix.com/browse/ZBX-4831
Hide
Pavel Timofeev added a comment -

Jim, does proc.mem work for you?

Show
Pavel Timofeev added a comment - Jim, does proc.mem work for you?
Hide
Pavel Timofeev added a comment -

Jim's patch applied
[root@octans ]# ps -axo vsz,rss,command | grep syslogd
12184 1340 /usr/sbin/syslogd -s
[root@octans ]# zabbix_get -s octans -I 192.168.2.6 -k 'proc.mem[syslogd]'
2232320

2232320 Bytes = 2180 KBytes but != 12184 KBytes or 1340 KBytes returned by ps

Show
Pavel Timofeev added a comment - Jim's patch applied [root@octans ]# ps -axo vsz,rss,command | grep syslogd 12184 1340 /usr/sbin/syslogd -s [root@octans ]# zabbix_get -s octans -I 192.168.2.6 -k 'proc.mem[syslogd]' 2232320 2232320 Bytes = 2180 KBytes but != 12184 KBytes or 1340 KBytes returned by ps
Hide
Jim Riggs added a comment -

The "memory usage" of a process is a controversial and subjective topic. There are many different views about what actually constitutes a proc's memory usage.

Currently, the zabbix code is using text size + data size + stack size for proc.mem (ki_tsize + ki_dsize + ki_ssize), whereas `top' and `ps' display resident size (ki_rssize) and VM size (ki_size). This is why the values from zabbix vs. top and ps are different. I would think that to eliminate confusion and to make the zabbix value more "verifiable," we should probably switch to using ki_rssize.

Thoughts? What are other OSes doing? I haven't dug into the linux code, for example.

Show
Jim Riggs added a comment - The "memory usage" of a process is a controversial and subjective topic. There are many different views about what actually constitutes a proc's memory usage. Currently, the zabbix code is using text size + data size + stack size for proc.mem (ki_tsize + ki_dsize + ki_ssize), whereas `top' and `ps' display resident size (ki_rssize) and VM size (ki_size). This is why the values from zabbix vs. top and ps are different. I would think that to eliminate confusion and to make the zabbix value more "verifiable," we should probably switch to using ki_rssize. Thoughts? What are other OSes doing? I haven't dug into the linux code, for example.
Hide
richlv added a comment -

i suppose we will want to match some value(s) from standard tools like ps if only to reduce the confusion - as noted, there is no definite "used memory" value, it's all quite relative.

Show
richlv added a comment - i suppose we will want to match some value(s) from standard tools like ps if only to reduce the confusion - as noted, there is no definite "used memory" value, it's all quite relative.
Hide
Jim Riggs added a comment -

Attached is proc.c+rss.patch which includes the original patch plus a switch to using the resident size for proc.mem as discussed. This works for me in FreeBSD 8 and 9 for single and multiple processes.

It would be nice to get these issues fixed sooner rather than later, if possible. The proc.num issue, specifically, has been causing problems for quite some time.

Show
Jim Riggs added a comment - Attached is proc.c+rss.patch which includes the original patch plus a switch to using the resident size for proc.mem as discussed. This works for me in FreeBSD 8 and 9 for single and multiple processes. It would be nice to get these issues fixed sooner rather than later, if possible. The proc.num issue, specifically, has been causing problems for quite some time.
Jim Riggs made changes -
Attachment proc.c+rss.patch [ 18765 ]
Hide
Jim Riggs added a comment -

I guess the question still remains, is resident size what people expect from proc.mem or VM size? Resident is closer to what the value was before, but VM size might give a better picture of actual memory footprint.

Hrm. Looking at the Linux agent, it is pulling the VM size (vsz). We should probably match. New patch coming...

Show
Jim Riggs added a comment - I guess the question still remains, is resident size what people expect from proc.mem or VM size? Resident is closer to what the value was before, but VM size might give a better picture of actual memory footprint. Hrm. Looking at the Linux agent, it is pulling the VM size (vsz). We should probably match. New patch coming...
Jim Riggs made changes -
Attachment proc.c+rss.patch [ 18765 ]
Hide
Jim Riggs added a comment -

OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.

Show
Jim Riggs added a comment - OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.
Jim Riggs made changes -
Attachment proc.c+vsz.patch [ 18766 ]
Hide
Oleksiy Zagorskyi added a comment -

Jim, I'm sorry, it's not related to proc.mem, but do you know about changes for agent 2.0 ?
http://blog.zabbix.com/when-alexei-isnt-looking/#vm.memory.size implemented here: ZBXNEXT-1024
Would be good to follow latest ideology

I think would be better to not mix here discussion about proc.num and proc.mem

Also see ZBXNEXT-1078 and ZBX-4532

Show
Oleksiy Zagorskyi added a comment - Jim, I'm sorry, it's not related to proc.mem, but do you know about changes for agent 2.0 ? http://blog.zabbix.com/when-alexei-isnt-looking/#vm.memory.size implemented here: ZBXNEXT-1024 Would be good to follow latest ideology I think would be better to not mix here discussion about proc.num and proc.mem Also see ZBXNEXT-1078 and ZBX-4532
Hide
Pavel Timofeev added a comment -

Oleksiy Zagorskyi, ZBXNEXT-1024 is not relative feature/fix. ZBXNEXT-1024 is on a different plane.

Show
Pavel Timofeev added a comment - Oleksiy Zagorskyi, ZBXNEXT-1024 is not relative feature/fix. ZBXNEXT-1024 is on a different plane.
Hide
Pavel Timofeev added a comment -

> Jim Riggs added a comment - 2012 Apr 26 07:07
> OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.

Excellent, Jim! Patch works fine on FreeBSD 9-RELEASE amd64. I hope this patch will be included in the nearest release.

Show
Pavel Timofeev added a comment - > Jim Riggs added a comment - 2012 Apr 26 07:07 > OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9. Excellent, Jim! Patch works fine on FreeBSD 9-RELEASE amd64. I hope this patch will be included in the nearest release.
Alexander Vladishev made changes -
Assignee Alexander Vladishev [ sasha ]
Alexander Vladishev made changes -
Status Confirmed [ 10000 ] In Progress [ 3 ]
Hide
Alexander Vladishev added a comment -

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3897

Fixed incorrect processing of proc.num[] item.
proc.mem[] item will be fixed later under ZBXNEXT-1078 or ZBX-4532.

Show
Alexander Vladishev added a comment - Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3897 Fixed incorrect processing of proc.num[] item. proc.mem[] item will be fixed later under ZBXNEXT-1078 or ZBX-4532.
Alexander Vladishev made changes -
Status In Progress [ 3 ] Resolved [ 5 ]
Assignee Alexander Vladishev [ sasha ]
Resolution Fixed [ 1 ]
dimir made changes -
Assignee Vladimir Levijev [ dimir ]
Hide
dimir added a comment -

I wonder why do I get less processes with zabbix get on FreeBSD 7.3. I tried 1.8.5, latest 1.8 with and without the fix:

$ uname -a
FreeBSD freebsd73.zabbix.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 06:15:01 UTC 2010 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

$ ps ax|wc -l
81

$ bin/zabbix_get -s 127.0.0.1 -k agent.version
1.8.5
$ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
39

$ bin/zabbix_get -s 127.0.0.1 -k agent.version
1.8.13rc1

  1. without the fix
    $ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
    39
  2. with the fix
    $ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
    39
Show
dimir added a comment - I wonder why do I get less processes with zabbix get on FreeBSD 7.3. I tried 1.8.5, latest 1.8 with and without the fix: $ uname -a FreeBSD freebsd73.zabbix.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 06:15:01 UTC 2010 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ ps ax|wc -l 81 $ bin/zabbix_get -s 127.0.0.1 -k agent.version 1.8.5 $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39 $ bin/zabbix_get -s 127.0.0.1 -k agent.version 1.8.13rc1
  1. without the fix $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39
  2. with the fix $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39
Hide
dimir added a comment -

It appeared to be a problem on my side, please ignore the comment above.

Show
dimir added a comment - It appeared to be a problem on my side, please ignore the comment above.
Hide
dimir added a comment -

Successfully tested, now the number of processes is reported properly.

Show
dimir added a comment - Successfully tested, now the number of processes is reported properly.
dimir made changes -
Status Resolved [ 5 ] Tested [ 10002 ]
dimir made changes -
Assignee Vladimir Levijev [ dimir ] Alexander Vladishev [ sasha ]
Hide
Alexander Vladishev added a comment - - edited

Fixed in versions pre-1.8.14 r27534, pre-2.0.1 r27689, pre-2.1.0 (beta) r27694

Show
Alexander Vladishev added a comment - - edited Fixed in versions pre-1.8.14 r27534, pre-2.0.1 r27689, pre-2.1.0 (beta) r27694
Alexander Vladishev made changes -
Status Tested [ 10002 ] Closed [ 6 ]
Assignee Alexander Vladishev [ sasha ]
Fix Version/s 1.8.14rc1 [ 11203 ]
Fix Version/s 2.0.1rc1 [ 10902 ]
Fix Version/s 2.1.0 (trunk) [ 11301 ]
Fix Version/s 2.0.0 [ 10402 ]

People

  • Assignee:
    Unassigned
    Reporter:
    gescheit
Vote (4)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: