Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
Hi, 2013/6/7 Craig Small csm...@debian.org: I'm the procps maintainer (Debian and upstream). Dmitry asked me to have a look at this bug as pgrep was discussed. My first impression is that there is some confusion between command line and process name. Digging deeper, that is the correct impression. Indeed, now I see that all the other correctly monitored processes don't have the full path, only '/usr/sbin/spamd' has it. So, we have a process, pgrep finds it, zabbix_agent doesn't. Obviously they are doing things differently, but what? Actually, not even pgrep finds it if --exact or -x is used. That is because if looks for an exact match of spamd but there is /usr/sbin/spamd. It's not clear why it doesn't find the child processes: | # pgrep -fl spamd | 31238 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -d | --pidfile=/var/run/spamd.pid | 31246 spamd child | 31247 spamd child Comparing 'spamd' with 'spamass-milter' I see this: | # ps -e -o pid,comm,cmd -f 31238 | PID COMMAND CMD | 31238 /usr/sbin/spamd /usr/sbin/spamd --create-prefs [..] | # ps -e -o pid,comm,cmd -f 3841 | PID COMMAND CMD | 3841 spamass-milter /usr/sbin/spamass-milter -P [..] | # ps -e -o pid,comm,cmd -f 31246 | PID COMMAND CMD | 31246 spamd child spamd child So why did spamd not show up? My strong assumption is that its command line looks different to its process name. There might be something else happening here, but at the very least you can easily discount this. Maybe this is a bug in 'spamd' that is registers bogus process names (ie. full path). Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
Hi, I'm the procps maintainer (Debian and upstream). Dmitry asked me to have a look at this bug as pgrep was discussed. My first impression is that there is some confusion between command line and process name. Digging deeper, that is the correct impression. So, we have a process, pgrep finds it, zabbix_agent doesn't. Obviously they are doing things differently, but what? pgrep, by default, uses the process name which what most tools show by default. You can see the difference with ps -e -o pid,comm,cmd which shows the pid, the process name and the command line. What does zabbix use? Looking in src/libs/zbxsysinfo/linux/proc.c we see this: if (FAIL == check_procname(f_cmd, f_stat, procname)) and what is f_cmd? zbx_snprintf(tmp, sizeof(tmp), /proc/%s/cmdline, entries-d_name); if (NULL == (f_cmd = open_proc_file(tmp))) cmdline is the command line, NOT the process name. If you want to use pgrep to check the command line, then use the -f flag. So why did spamd not show up? My strong assumption is that its command line looks different to its process name. There might be something else happening here, but at the very least you can easily discount this. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 signature.asc Description: Digital signature
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
2013/6/5 Dmitry Smirnov only...@member.fsf.org: `pgrep` is searching for substring in process name. For example if I have `konsole` running the `pgrep konso` will return PID even though there is no process konso running. proc.num is checking for exact process name so it will return 0 for `zabbix_get -s localhost -k 'proc.num[konso]'` and 1 for `zabbix_get -s localhost -k 'proc.num[konsole]'` I know, that's why I wrote the console output. In my case, 'spamd' is the exact process name. | $ pgrep -l spamd | 854 /usr/sbin/spamd | 858 spamd child | 859 spamd child Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
Package: zabbix-server-mysql
Version: 1:2.0.6+dfsg-1
Severity: normal
(real version is ~bpo70+1)
Hi,
The proc.num[spamd] always reports 0, web frontend or command line:
| root@return:~# zabbix_get -s localhost -k 'proc.num[spamd]'
| 0
| root@return:~# zabbix_get -s localhost -k 'proc.num[spamass-milter]'
| 1
All other proc.num checks appear to be correct (ex. spamass-milter).
It's a mistery why spamd gives 0 all the time.
On the system pgrep reports three running processes:
| root@return:~# pgrep spamd
| 5697
| 5699
| 5700
| root@return:~# pgrep spamass-milter
| 3841
This problem has appeared on both Zabbix 1.8.2 and 2.0.6 after the system
was upgraded to Debian 7.0.
Cheers
-- System Information:
Debian Release: 7.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages zabbix-server-mysql depends on:
ii adduser 3.113+nmu3
ii fping 3.2-1
ii libc6 2.13-38
ii libcurl3-gnutls 7.26.0-1+wheezy2
ii libiksemel3 1.2-4
ii libldap-2.4-2 2.4.31-1+nmu2
ii libmysqlclient18 5.5.31+dfsg-0+wheezy1
ii libopenipmi0 2.0.16-1.3
ii libsnmp15 5.4.3~dfsg-2.7
ii libssh2-1 1.4.2-1.1
ii lsb-base 4.1+Debian8
ii ucf 3.0025+nmu3
Versions of packages zabbix-server-mysql recommends:
ii mysql-server 5.5.31+dfsg-0+wheezy1
ii snmpd 5.4.3~dfsg-2.7
Versions of packages zabbix-server-mysql suggests:
ii logrotate3.8.1-4
ii zabbix-frontend-php 1:2.0.6+dfsg-1~bpo70+1
-- Configuration Files:
/etc/default/zabbix-server changed:
START=yes
/etc/logrotate.d/zabbix-server-mysql changed:
/var/log/zabbix-server/zabbix_server.log {
daily
rotate 7
compress
missingok
notifempty
create 0640 zabbix adm
sharedscripts
}
-- debconf information:
zabbix-server-mysql/upgrade-error: abort
zabbix-server-mysql/dbconfig-reinstall: false
zabbix-server-mysql/upgrade-backup: true
zabbix-server-mysql/missing-db-package-error: abort
zabbix-server-mysql/mysql/admin-user: root
zabbix-server-mysql/remote/port:
zabbix-server-mysql/remote/host:
zabbix-server-mysql/db/dbname: zabbix
zabbix-server-mysql/dbconfig-remove:
zabbix-server-mysql/db/app-user: zabbix
zabbix-server-mysql/database-type: mysql
zabbix-server-mysql/internal/skip-preseed: false
zabbix-server-mysql/remove-error: abort
zabbix-server-mysql/server:
zabbix-server-mysql/remote/newhost:
zabbix-server-mysql/purge: false
zabbix-server-mysql/internal/reconfiguring: false
zabbix-server-mysql/install-error: abort
zabbix-server-mysql/passwords-do-not-match:
* zabbix-server-mysql/dbconfig-install: true
zabbix-server-mysql/mysql/method: unix socket
zabbix-server-mysql/dbconfig-upgrade: true
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
Dear Teodor, `zabbix_get` query zabbix-agent directly so if there is a problem it is not in zabbix-server but in zabbix-agent. `pgrep` is searching for substring in process name. For example if I have `konsole` running the `pgrep konso` will return PID even though there is no process konso running. proc.num is checking for exact process name so it will return 0 for `zabbix_get -s localhost -k 'proc.num[konso]'` and 1 for `zabbix_get -s localhost -k 'proc.num[konsole]'` . You might need to update your item(s) to check for exact process name. Please confirm if this information helped so I could close this bug. Thanks. Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
