[ZBX-9317] proc.* checks return ZBX_NOTSUPPORTED when user doesn't exist Created: 2015 Feb 17 Updated: 2017 May 30 Resolved: 2015 Mar 23 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Agent (G) |
| Affects Version/s: | 2.4.2 |
| Fix Version/s: | 2.5.0 |
| Type: | Incident report | Priority: | Major |
| Reporter: | Sydney | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | items, proc.mem, proc.num | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I've configured some checks on Zabbix servers for my infra. One of which is a check for tomcat. The key for the item is "proc.num[java,tomcat,,tomcat7]" On servers that have tomcat running the check works perfectly fine. On servers that don't have tomcat running I would expect it to return a value of 0 but in this case it returns ZBX_NOTSUPPORTED. Logically I would assume that ZBX_NOTSUPPORTED would refers to incorrectly configured items. But here the item & key are correct but is shown as ZBX_NOTSUPPORTED. If I change the key to proc.num[java], it returns a 0 & that is what I would also expect of the above mentioned key. Can this be achieved or is it a default behaviour that cannot be changed? I would like to see it changed so that there is a distinction between incorrectly configured keys that are actually not supported or have a syntax error & checks that should return a zero as in the case above. Similar behaviour is also observed for other items that check processes and if the user name specificed in the key does not exist |
| Comments |
| Comment by richlv [ 2015 Feb 17 ] |
|
confirming in current trunk; this happens when the user does not exist at all |
| Comment by Sydney [ 2015 Feb 26 ] |
|
Why has it been configured to return ZBX_NOTSUPPORTED? If i check only for process it would return either a 0 or a 1. If i check for a combination of process and user it return ZBX_NOTSUPPORTED if user doesnt exist. Logically it should have returned 0 Is this behaviour going to be fixed or does the team deem it to be normal? |
| Comment by richlv [ 2015 Feb 26 ] |
|
personally, i'd agree that it is a functional bug. it has not been investigated in more detail yet, though |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 04 ] |
|
In version 2.4.2 and the described scenario, the item should become not supported with the following error message: "Specified user does not exist." (not just ZBX_NOTSUPPORTED). |
| Comment by Sydney [ 2015 Mar 04 ] |
|
I'm using zabbix 2.4.2-1 but it returns ZBX_NOTSUPPORTED only. |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 04 ] |
|
How do you query the agent so that it returns ZBX_NOTSUPPORTED only? Using "zabbix_agentd -t proc.num[java,tomcat,,tomcat7]", zabbix_get or Zabbix server? If latter, which server version do you use? |
| Comment by Sydney [ 2015 Mar 05 ] |
|
The zabbix versions on zabbix server and zabbix proxy are 2.4.2-1. I've tried it with the zabbix get command from the proxy server Even the zabbix_agentd command returns [m|ZBX_NOTSUPPORTED] but the zabbix_agent version is 2.2.1-1 |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 05 ] |
|
Error messages for unsupported agent items are available since Zabbix 2.4, introduced in |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 05 ] |
|
It was decided to change the behavior of proc.mem[] and proc.num[] to return 0 in case the specified user does not exist. This change is available in development branch svn://svn.zabbix.com/branches/dev/ZBX-9317 . |
| Comment by Andris Zeila [ 2015 Mar 09 ] |
|
(1) If the user does not exist proc.mem[<name>,<user>,<mode>,<cmdline>,<memtype>] always returns an unsigned type value 0, while normally (depending on <mode> and <memtype>) it can return floating point value: > zabbix_agentd -t 'proc.mem[eclipse,user,avg]' proc.mem[eclipse,user,avg] [d|11128832.000000] > zabbix_agentd -t 'proc.mem[eclipse,invaliduser,avg]' proc.mem[eclipse,invaliduser,avg] [u|0] It would be nice to keep value type consistent and return floating value type value 0 in such situation. asaveljevs Another thing that should be fixed is that the value of 0 for a non-existent user should only be returned after all parameters have been parsed and validated. asaveljevs Fixed in r52634. RESOLVED. wiper CLOSED |
| Comment by Andris Zeila [ 2015 Mar 12 ] |
|
Successfully tested |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 13 ] |
|
Available in pre-2.5.0 (trunk) r52718. |
| Comment by Aleksandrs Saveljevs [ 2015 Mar 13 ] |
|
Documented at the following locations:
sasha CLOSED |