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).

Changed in procps (Ubuntu):

status:

Invalid → New

summary:

- pgrep cuts process names+ pgrep does not correctly match the input of the user against the process+ name

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.

summary:

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

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?