Bug 460795 - /etc/cron.daily/readahead.conf references nonexistent /etc/readahead.d/*.later
/etc/cron.daily/readahead.conf references nonexistent /etc/readahead.d/*.later
Product: Fedora
Classification: Fedora
Component: readahead (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
Reported: 2008-09-01 03:28 EDT by Valdis Kletnieks
Modified: 2008-10-17 23:47 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-17 23:47:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Make readahead.cron look for the right filenames... (359 bytes, patch)
2008-09-01 03:30 EDT, Valdis Kletnieks
no flags Details | Diff

  None (edit)
Description Valdis Kletnieks 2008-09-01 03:28:19 EDT
Description of problem:
cronjob throws an error message:


ls: cannot access /etc/readahead.d/*.later: No such file or directory

Looking at the code, it appears that the script and the packaging of the readahead.d directory are confused whether the files are '*.later' or 'later.*'. I've attached a patch to change the script to match what's actually in the directory.  Alternatively, the files could be renamed to match what the script is expecting.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Valdis Kletnieks 2008-09-01 03:30:45 EDT
Created attachment 315457 [details]
Make readahead.cron look for the right filenames...
Comment 2 Jonathan Kamens 2008-09-02 14:48:53 EDT
I also get an error about /etc/readahead.d/*.early:


ls: cannot access /etc/readahead.d/*.early: No such file or directory
ls: cannot access /etc/readahead.d/*.later: No such file or directory
Comment 3 Ville Skyttä 2008-10-02 14:50:26 EDT
I see it too.  Would probably be better to redirect stderr of the "ls" to /dev/null as it's seemingly not at all unlikely that some of the files are not there (for example, I have neither *.later or later.*).

Also, the srpm contains default.{early,later} which are copied into place in %prep and then later simply removed in %install - I suppose those could be just dropped.
Comment 4 Michal Jaegermann 2008-10-16 17:22:36 EDT
Well, really an output from 'ls' should not be used in scripts (unless there are really good reasons and this does not seem to be the case).  Quite possibly
something like that was intended:

   FLS=$( shopt -s nullglob; echo $READAHEAD_BASE/*$LTYPE* )

although I am not entirely sure how to guess from what I see. The main
loop of this script may look somewhat like that (with possibly different
globbing; I cannot really tell):

shopt -s nullglob
for LTYPE in $TYPES; do
   FLS=$(echo $READAHEAD_BASE/*custom.$LTYPE)
   [ -n "$FLS" ] || FLS=$(echo $READAHEAD_BASE/*$LTYPE*)
   [ -n "$FLS" ] || continue
Comment 5 Harald Hoyer 2008-10-17 23:47:30 EDT
will change to a better globbing. rawhide pipes to /dev/null

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