Bug 460715
Summary: | readahead tries to execute when it is not available | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | readahead | Assignee: | Karel Zak <kzak> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | harald, marco.crosio, valdis.kletnieks |
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-09 19:04:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michal Jaegermann
2008-08-30 02:21:18 UTC
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. |