Hi, 2013/6/7 Craig Small <[email protected]>: > 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
