Bug 204082 - oprofiled fails to start when a path name is > NAME_MAX
Summary: oprofiled fails to start when a path name is > NAME_MAX
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: oprofile
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: William Cohen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-25 13:56 UTC by Chris Lalancette
Modified: 2012-06-20 15:59 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-06-20 15:59:59 UTC


Attachments (Terms of Use)

Description Chris Lalancette 2006-08-25 13:56:18 UTC
+++ This bug was initially created as a clone of Bug #204081 +++

Description of problem:
When starting up the oprofile daemon via "opcontrol --start --verbose", if any
component of the file names being profiles have path names > NAME_MAX (which
happens to be 255 on RHEL4), oprofiled will fail with a ENAMETOOLONG.  While
this is a limitation of the path names, it might make sense to detect when names
are too long, and use some sort of hash to shorten them up.  I assume this would
also be the case if the entire path was > PATH_MAX (which is 4096 in RHEL4), but
I have not tested that to confirm.

Comment 1 Jiri Pallich 2012-06-20 15:59:59 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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