pgrep does at default not always match the input of the user against the process name

confirmed on ubuntu 12.04

confirmed on 14.04

Confirmed on latest Xenial:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04
Codename: xenial

Related to LP #295876 'top and ps truncate command after 15 chars' at <https://bugs.launchpad.net/ubuntu/+source/procps/+bug/295876>.

As per comment #3 to LP #295876 (<https://bugs.launchpad.net/ubuntu/+source/procps/+bug/295876/comments/3>), The root cause seems to be that pgrep gets the process's name from /proc/<pid>/status instead of /proc/<pid>/cmdline; in the former case, the name is truncated to 15 characters:

$ python3 -c 'print(len("chromium-browser"))'
16
$ pgrep chromium-browser
echo $?
1 # exit status code 1 == no processes matched (as per man page for pgrep(1))
$ pgrep chromium-browse
22351
22364
[snip]

$ cat /proc/22351/cmdline && echo
chromium-browser --enable-pinch
$ cat /proc/22351/status | grep Name
Name: chromium-browse

A correction to my previous comment:

<https://bugs.launchpad.net/ubuntu/+source/procps/+bug/295876/comments/3> states that pgrep gets the process' name from /proc/<pid>/stat, not /proc/<pid>/status, as I wrote, and appears to be correct.

cat /proc/22351/stat
22351 (chromium-browse) S 1616 1829 1829 0 -1 4194560 31046 20451 701 0 468 160 6 2 20 0 31 0 355501 1271119872 38692 18446744073709551615 94135085649920 94135125690420 140723151897424 140723151896160 140132228684269 0 0 4096 81923 0 0 0 17 3 0 0 64 0 0 94135127791120 94135129570812 94135143915520 140723151902368 140723151902426 140723151902426 140723151904717 0

/proc/<pid>/status itself gets its info from /proc/<pid>/stat and /proc/<pid>/statm.

<https://bugs.launchpad.net/ubuntu/+source/procps/+bug/295876/comments/3> led me to review pgrep(1)'s man page (which it references).

Under 'NOTES', the man page states:

"The process name used for matching is limited to the 15 characters present in the output of /proc/pid/stat. Use the -f option to match against the complete command line, /proc/pid/cmdline."

Therefore, this is not a bug, even though it is arguable that the behaviour of pgrep(1)'s default invocation is not intuitive. Accordingly, this can be closed as invalid.

This is indeed useful information you have found but makes the bug not invalid as this means pgreps matching behavior is defect as demonstrated in the startpost. If pgrep matches against cut process names it should also internally cut the input of the user (or automatically switch to /proc/_pid_/cmdline if pgrep notices that the input of the user is too long and could never return a match).

Edit: Meh, on looking at the manpage I remembered the argument is a pattern which can make the above very tricky. Alternatively pgrep could really fallback to /proc/_pid_/cmdline on failure or use -f as default.

Edit2: On thinking about this a bit more the difference between using -f or not is the matching against the process name only and matching against the full command line (process name + arguments). Theoretically matching against the process name only could also be done if pgrep would use /proc/_pid_/cmdline instead and just cut its content before the first argument. That would all keep as it is but the character limit would be eliminated. Or is there a special reason why pgrep does get the process name from /proc/_pid_/stat?

Status changed to 'Confirmed' because the bug affects multiple users.