Bug 1011926

Summary: process names with two dashes are wrongly detected
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: procps-ngAssignee: Jaromír Cápík <jcapik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: jcapik, ovasik
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-26 16:52:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kamil Páral 2013-09-25 12:05:32 UTC
Description of problem:

$ pgrep -a gnome-settings
1611 /usr/libexec/gnome-settings-daemon
$ pgrep -a gnome-settings-daemon
$ 


$ pgrep -fl gnome-settings
1611 gnome-settings-
$ pgrep -fa gnome-settings
1611 /usr/libexec/gnome-settings-daemon

It's very weird. I suspect two dashes in process name break pgrep badly.

Version-Release number of selected component (if applicable):
procps-ng-3.3.8-10.fc19.x86_64

How reproducible:
always

Comment 1 Jaromír Cápík 2013-10-02 14:58:50 UTC
Ahoj Kamile.

The behaviour is perfectly correct. 

The manual says:
------------------
-f, --full
The pattern is normally only matched against the process name.  When -f is set, the full command line is used.
------------------

The maximum process name length in the kernel is 15 characters (+null terminator). That's why the -f switch gave you the correct result. And maybe you've noticed, the result is truncated to 15 characters as well.
Try to match the process as 'gnome-settings-'. You should get what you want.

I'm closing this report as NOTABUG. Feel free to reopen if you still believe it doesn't work correctly.

Thank you.

Regards,
Jaromir.

Comment 2 Kamil Páral 2013-10-02 17:58:42 UTC
Thanks, Jaromir, for your explanation. I had no idea kernel has process name limits so low. Could this at least be mentioned in the man page? I guess there are many people like me who have no idea of the 15-character limit.

Comment 3 Jaromír Cápík 2013-10-02 18:10:21 UTC
I'm unsure this is a good idea as we would duplicate the kernel documentation. What if the kernel behavior changes one day? I'll ask the rest of the procps-ng team what they think.

Comment 4 Kamil Páral 2013-10-02 18:22:14 UTC
Come on! People don't read kernel documentation just because they want to use pgrep! :-) (Moreover when they have no idea that it's related).

How often that changes? Once in a decade? The man page can be adjusted if/when that happens.

In the worst case, it could say something like "There is a length limit imposed on process names. For exact values refer to ...". But I would really recommend to include the number as well.

Comment 5 Jaromír Cápík 2013-10-03 11:50:48 UTC
(In reply to Kamil Páral from comment #4)
> Come on! People don't read kernel documentation just because they want to
> use pgrep! :-) (Moreover when they have no idea that it's related).

We could state the process name length is limited to 15 chars and the limit may change in the future. That's probably the only acceptable way.


> How often that changes? Once in a decade? The man page can be adjusted
> if/when that happens.

... and somebody would have to check for such changes periodically ... that's exactly what we don't want to do.

I'm going to create an upstream commit and wait for the comments. I'll apply the diff locally only if it's accepted by the rest of the upstream members.

Comment 6 Jaromír Cápík 2013-11-26 16:52:12 UTC
Ahoj Kamile. 

The funny thing is, that the length limit is already mentioned in the manual. Look at the NOTES. 
And guess what. The change is older than 11 years. In fact it's probably much older, but I'm unable to track the origin as the oldest git commit is dated to 1-Feb-2002.

I hope you won't be against if I close this ticket as NOTABUG again.

Regards,
Jaromir.

Comment 7 Kamil Páral 2013-11-27 09:40:02 UTC
Ah, you're right. Thanks.