Red Hat Bugzilla – Bug 460715
readahead tries to execute when it is not available
Last modified: 2008-09-09 15:04:25 EDT
Description of problem: When booting I see the following: ..... Switching to new root and running init. /bin/sh: line 2: /usr/sbin/readahead: No such file or directory init: readahead.event main process (593) terminated with status 1 init: readahead-collector.event post-stop process (595) terminated with status 1 Welcome to Fedora ...... Apparently these are results of an attempted execution of /etc/event.d/readahead.event This cannot work as /usr is not mounted yet. Whatever is required in a boot seqence before mounts has to be available on /. An error can be avoided by checking in readahead.event for a presence of /usr/sbin/readahead before attempting to "exec" it but that clearly breaks readahead. /sbin/readahead would be nicer if that cannot be delayed after mounts are done. Version-Release number of selected component (if applicable): readahead-1.4.5-1.fc10 How reproducible: always
should be fixed with readahead-1.4.5-2.fc10
With readahead-1.4.5-2.fc10 I still see the following: Switching to new root and running init. init: readahead-collector.event post-stop process (596) terminated with status 1 Welcome to Fedora I am not sure why. Is this expected? Moving readahead to /sbin/readahead indeed removes "No such file or directory" but readahead will apply only to file systems which are mounted in this moment, i.e. /. Is this really intended?
In /etc/readahead.conf I see # Ignore syscalls from: RAC_EXECIGN="/usr/sbin/readahead" That does not look right after recent changes. Also from descriptions in /usr/share/doc/readahead-1.4.5/ it does not sound that this can work correctly if it runs before file systems are mounted. An algorithm described there which does "open, stat, ...." will fail on "open" apparently in most cases.
Re: comment #3 - there's a reason why there's .early and .later files - the algorithm works just fine if you start it in rc.sysinit with a .early that only references files in /, and then you re-kickstart it early in rc5.d with a .later list that includes stuff in /usr after it's been mounted...
Re: comment #4. I have to plead ignorance how this works in details but I looked at this early.sorted list in /etc/readahead.d/ and found there numerous names starting with /usr/bin and /usr/sbin. To wit: .... 319520 /usr/sbin/crond 146984 /usr/sbin/console-kit-daemon 470552 /usr/sbin/sshd 27584 /usr/sbin/atd 220504 /usr/sbin/automount 12536 /usr/bin/free 820840 /usr/sbin/sendmail.sendmail 7656 /usr/sbin/selinuxenabled .... Also /usr/lib/ and /usr/lib64/ were amply present.
Looks like you're right, but only because somebody changed it since last I looked closely at it - It appears that readahead 1.4.5 uses some funky stuff to do "adaptive" readahead. In 1.4.4 it worked differently (a early list for the first part of boot, then a 'later' list for after /usr and so on)...
have a look in /etc/event.d/readahead.event. It waits maximum 10 seconds until /usr is mounted. > init: readahead-collector.event post-stop process (596) terminated with status 1 Hmm, this should not happen. I will have a look
readahead-1.4.6 should fix the problem with selinux off.
Now readahead indeed does not come back with complaints. Thanks.