Bug 204082

Summary:	oprofiled fails to start when a path name is > NAME_MAX
Product:	Red Hat Enterprise Linux 4	Reporter:	Chris Lalancette <clalance>
Component:	oprofile	Assignee:	William Cohen <wcohen>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	clalance
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 15:59:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.