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

Bug #1174911 reported by Thomi Richards on 2013-04-30
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
High
Unassigned

Bug Description

When looking for a process with a long process name, pgrep cuts the process name, and so doesn't match an exact search. For example:

# launch gnome-calculator:
$ gnome-calculator

# use 'ps a' to show process table - note the whole process name is present:
$ ps a
  PID TTY STAT TIME COMMAND
 1411 tty4 Ss+ 0:00 /sbin/getty -8 38400 tty4
 1417 tty5 Ss+ 0:00 /sbin/getty -8 38400 tty5
 1427 tty2 Ss+ 0:00 /sbin/getty -8 38400 tty2
 1428 tty3 Ss+ 0:00 /sbin/getty -8 38400 tty3
 1436 tty6 Ss+ 0:00 /sbin/getty -8 38400 tty6
 9417 pts/1 Sl 0:00 gnome-calculator
 9426 pts/1 R+ 0:00 ps a

(some results cut for clarity)

# now try and find it with pgrep:
$ pgrep gnome-calculator

# no results! however, this works:
$ pgrep gnome-calculato

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: procps 1:3.3.3-2ubuntu5
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Tue Apr 30 13:35:02 2013
InstallationDate: Installed on 2012-01-17 (469 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MarkForUpload: True
SourcePackage: procps
UpgradeStatus: Upgraded to raring on 2012-12-05 (145 days ago)

Thomi Richards (thomir) wrote :
Changed in procps (Ubuntu):
status: New → Confirmed
importance: Undecided → High

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.

Changed in procps (Ubuntu):
status: Confirmed → Invalid
Sworddragon (sworddragon) wrote :

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
Sworddragon (sworddragon) wrote :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers