On Thursday, January 27, 2011 07:19:16 am Laszlo Papp wrote: > I have just faced into this issue weeks ago. > This is the related thread: > http://www.linuxquestions.org/questions/showthread.php?p=4231159#post423115 > 9 > > Any 2 cents on the matter or plan, schedule when to fix it ? I added user space support quite a while back and asked for kernel help. No one answered: http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html If no one wants to help, then I have to wait until someone finally decides to fix it. -Steve

On Friday, January 28, 2011 07:46:13 am Laszlo Papp wrote: > On Thu, Jan 27, 2011 at 3:53 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > If no one wants to help, then I have to wait until someone finally > > decides to fix it. > > I see, Steve. Unfortunately I cannot help because I do not have too > much kernel programming experience. The real problem why I wanted to > give a glimpse for AUDIT because upstart cannot print out the process > ID information about the commands that were run from the > pre/post-start/stop section of the /etc/init/*.conf upstart config/job > files. I suspect you could patch upstart to record this information. Where to put it is the main question since the only thing that might be accesible is /.

> I has been told so that audit could be used in this special case for > my purpose. The first question is that whether or not kernel's > audit-properties can be used without the SYSCALL configuration option > - so basically just with the "default one" -  to get more accurate > information about the processes upstart launches during the boot-up. Not really. You would have to patch upstart to send audit events. But assuming you had support for this on ARM processors, the audit system has a start priority of 11 using the old SysVinit style of startup. If you use LSB style startups, then you will find more disappointing news because my calls for an audit facility have also went unanswered. They have a syslog facility, but no one seems to care about audit. So, whenever the audit system finally starts up, you could use a rule like this: -a always,exit -S execve -F ppid=1 -k init and you can use the key, init, for searching ausearch --start today -k init There is a readahead collector that could probably be hacked to record process information rather than file loading information. The following location has some info and links on profiling startup: http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded