Bug 460715 - readahead tries to execute when it is not available
readahead tries to execute when it is not available
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: readahead (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-29 22:21 EDT by Michal Jaegermann
Modified: 2008-09-09 15:04 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-09 15:04:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-08-29 22:21:18 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
Comment 1 Harald Hoyer 2008-09-03 10:32:16 EDT
should be fixed with readahead-1.4.5-2.fc10
Comment 2 Michal Jaegermann 2008-09-05 14:22:06 EDT
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?
Comment 3 Michal Jaegermann 2008-09-05 15:58:26 EDT
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.
Comment 4 Valdis Kletnieks 2008-09-05 16:15:24 EDT
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...
Comment 5 Michal Jaegermann 2008-09-05 17:06:16 EDT
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.
Comment 6 Valdis Kletnieks 2008-09-05 18:25:55 EDT
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)...
Comment 7 Harald Hoyer 2008-09-06 04:34:28 EDT
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
Comment 8 Harald Hoyer 2008-09-08 09:47:08 EDT
readahead-1.4.6 should fix the problem with selinux off.
Comment 9 Michal Jaegermann 2008-09-09 15:04:25 EDT
Now readahead indeed does not come back with complaints.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.