Comment 34 for bug 523484

I just have a couple of thoughts on this bug.

* The earlier comment that ureadahead could just buffer this in memory and write later wouldn't be all that difficult to implement. The potential for a lot of data is unknown to me (on my two systems I checked, the file is around 700kb), so that may be a limiting factor. However, in reading the code, it seams ureadahead pretty much already just builds all of this up in memory and then flushes it out at one time anyway.

The real issue is that there won't be a pack file to read from until the real /var from the last profiling attempt is mounted anyway.

So I was thinking we should just install a SIGUSR1 handler, then try to access /var/lib/ureadahead .. if that works.. ignore SIGUSR1, then plow on as we do now.

If not, go to sleep. Every time we get woken up, repeat the logic above. Then we can add this upstart job:

# ureadahead-filesystem
start on mounted

env MOUNTPOINT=""
instance $MOUNTPOINT

task
exec killall -SIGUSR1 ureadahead
# EOF

This will send ureadahead a SIGUSR1 to try and open /var/lib/ureadahead every time a filesystem is mounted.

I suppose we could use SIGSTOP and SIGCONT too, but this feels a little less prone to stepping on ptrace's toes.