Bug 1011926 - process names with two dashes are wrongly detected
Summary: process names with two dashes are wrongly detected
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: procps-ng
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaromír Cápík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-25 12:05 UTC by Kamil Páral
Modified: 2016-02-01 01:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-26 16:52:12 UTC
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.