pgrep: allows long command lines to be searched e.g. java process with long classpath
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
procps (Ubuntu) |
Fix Released
|
Low
|
Eric Desrochers | ||
Xenial |
In Progress
|
Low
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Eric Desrochers | ||
Disco |
Fix Released
|
Low
|
Eric Desrochers |
Bug Description
[Impact]
The pgrep -f and pkill -f commands are unable to find processes strings in processes which are beyond the 4096th character. This often happens with Java command lines with long classpaths on the command line.
[Test Case]
A quick test to reproduce this is to vi a file using a filename over 4k
$ vi $(seq 1 1250| paste -s -d'_')_foo.txt)
and leave vi running then run from another terminal
$ pgrep -af 'foo.txt'
to find it.
Without the fix, one will only see the first 4096 chars, while the expected behaviour would be:
$ pgrep -af 'foo.txt'
27667 vi 1_2_3_4_
[Potential Regression]
The proposal merge are a few months old, and no upstream comment/involvement since then.
If we fix that in Ubuntu, we will have to carry the patch at each release until Upstream take action (if they take action one day). The patch is simple and easy to carry over.
The potential regression could be that one discard the patch in future merge, and re-introduce the previous CMDSTRSIZE value.(Due to the fact that upstream haven't accept the patch yet)
I don't foresee any problem in increasing the value from "4096 to "16384".
IMHO, it's a little bit too much, but will benefit user who uses java application with long classpath.
[Other Infos]
This bug is a mirror of what has already been reported in GitLab, through the merge request #85 [1], and has been previously reported at the merge request #80 [2], with no response/reply.
Let me know if further information is needed, at this point, to proceed. Thanks!
[1] https:/
[2] https:/
Upstream discussion:
https:/
tags: | added: sts |
Changed in procps (Ubuntu): | |
importance: | Undecided → Low |
assignee: | nobody → Eric Desrochers (slashd) |
status: | New → In Progress |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in procps (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in procps (Ubuntu Bionic): | |
status: | New → In Progress |
Changed in procps (Ubuntu Disco): | |
status: | New → In Progress |
Changed in procps (Ubuntu Xenial): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in procps (Ubuntu Bionic): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in procps (Ubuntu Disco): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in procps (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Disco): | |
importance: | Undecided → Low |
Changed in procps (Ubuntu Xenial): | |
importance: | Undecided → Low |
Changed in procps (Ubuntu): | |
status: | In Progress → Fix Committed |
summary: |
- pgrep: Use POSIX _SC_ARG_MAX for maximum pgrep -f command line length + pgrep: allows long command lines to be searched e.g. java process with + long classpath |
Changed in procps (Ubuntu Xenial): | |
assignee: | Eric Desrochers (slashd) → nobody |
The '-a' flag[0] which should list the full cmd line seems to be limited to 4096 chars[1].
In most case it is more than enough, but not always the case for java processes with long classpaths for instance as describe in the bug description.
[0] -a, --list-full
List the full command line as well as the process ID. (pgrep only.)
[1] pgrep.c
44
45 #define CMDSTRSIZE 4096
46