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.
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.
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.
there is no need for a logfile (a logfile would be counterproductive performance wise)
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...
yes, would be cool, but the audit team doesn't "want" these events ever cross their daemon...
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
(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
ok, not needed anymore