Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 454452

Summary: RFE: Need for a audit like interface for readahead-collector
Product: [Fedora] Fedora Reporter: Harald Hoyer <harald>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: ddumas, eparis, jmoyer, kmcmartin, mclasen, sgrubb
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: 2008-09-07 09:09:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Harald Hoyer 2008-07-08 16:05:16 UTC
To create an adaptive readahead 
http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded
we need a kernel interface to gather information about which files are
open(2)'ed and exec(2)'ed in the boot process. 

In it's current implementation readahead-collector uses the audit kernel
interface. Because the audit team wants the audit interface clean and only be
used by security related messages, we need either a second channel, or a
completely different solution.

Another solution would be systemtap, but this creates the overhead of compiling
a kernel module for every new kernel, which is suboptimal.

Comment 1 Dave Jones 2008-07-08 16:45:13 UTC
I suggest taking this upstream to linux-kernel.  
RFE's in bugzilla don't really work unless you have someone already signed up to
do the implementation.

Comment 2 Chuck Ebbert 2008-07-09 18:59:39 UTC
This could be done as an enhancement to auditd, by having it write out audit
records with a given key to a separate log file.


Comment 3 Harald Hoyer 2008-07-09 19:19:29 UTC
there is no need for a logfile (a logfile would be counterproductive performance
wise)

Comment 4 Chuck Ebbert 2008-07-09 23:27:10 UTC
Then all it needs is for an option to auditd to never log events with a special
key, then use that key for all the audit events used by the readahead collector.

Not sure what the implications are for auditd though.

I assume you are removing all your audit triggers after the system is up and
running...


Comment 5 Harald Hoyer 2008-07-10 08:10:15 UTC
yes, would be cool, but the audit team doesn't "want" these events ever cross
their daemon...

Comment 6 Kyle McMartin 2008-07-10 19:14:42 UTC
How about just hacking a minimilist strace into upstart? I've (somewhat
unfortunately :) become familiar with the guts of strace to feel comfortable
implementing such a thing. Hit me up in email or irc to hash out the details if
this sounds like it would fly.

cheers, Kyle

Comment 7 Harald Hoyer 2008-07-11 07:52:10 UTC
(In reply to comment #6)
> How about just hacking a minimilist strace into upstart? I've (somewhat
> unfortunately :) become familiar with the guts of strace to feel comfortable
> implementing such a thing. Hit me up in email or irc to hash out the details if
> this sounds like it would fly.
> 
> cheers, Kyle

not an option for everydays boot process



Comment 8 Harald Hoyer 2008-09-07 09:09:35 UTC
ok, not needed anymore