Bug 87583 - updatedb not run after install of shrike
Summary: updatedb not run after install of shrike
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: firstboot
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
: 81084 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-29 06:43 UTC by greg hosler
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-03-31 17:10:14 UTC

Attachments (Terms of Use)

Description greg hosler 2003-03-29 06:43:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

Description of problem:
after shrike is installed, and firstboot completes, updatedb still needs to be
manually run.

even after a secondary reboot (after configuring some settings manually),
updatedb is not run on the reboot.

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

How reproducible:
Didn't try

Steps to Reproduce:
1. install shrike
2. after firstboot, wait 5 minutes (just to be fair) try a "locate"
3. reboot, (wait 5 minutes again, just to be extra fair) and try again

Actual Results:  updatedb is not automatically run after firstboot

Expected Results:  firstboot should spawn off a updatedb, _or_ anacron should
recognize that the system is freshly installed, and should do the nightly stuff
upon first (or re) boot, esp updatedb

Additional info:

Comment 1 Dax Kelson 2003-03-30 05:33:05 UTC
Anacron runs missed /etc/cron.daily (such as updatedb) tasks 65 mins after boot.

So, of course it won't work 5 mins after you boot it, after a fresh install.

I can see the benefit of firstboot running it though.

Comment 2 Brent Fox 2003-03-31 17:10:14 UTC
The problem with doing this is that it makes some machines really slow in
responding during firstboot and/or first login.  People were complaining that
the system that they had just installed was feeling very sluggish.  

I don't think we want to change the current behavior.

Comment 3 Brent Fox 2003-04-01 20:56:59 UTC
*** Bug 81084 has been marked as a duplicate of this bug. ***

Comment 4 Chris Ricker 2003-04-01 21:06:45 UTC
What the original bug #81084 suggested was a little different than what you're
dismissing here in this bug.

What it suggested was an option within firstboot (disabled by default) which
offered to do initial preparation of the system now, and warns that the system
might be slow while it runs makewhatis, updatedb, etc..... Is that still a
WONTFIX as well?

Comment 5 Brent Fox 2003-04-01 21:22:44 UTC
Yes.  I really don't want to put a button in firstboot that says, "Click here to
run makewhatis"  No amount of help text is going to be able to explain that to a
new user. 

It's the same reason I don't want to put a screen about runlevels in firstboot.
 The vast majority of the computer using world has no idea what a 'runlevel' is

I think that the right answer is just to wait until anacron runs it on it's own.
 Or you can start it up yourself after firstboot is through.  For most people,
anacron will get around to it soon enough.

Comment 6 Richard Lloyd 2003-04-01 23:03:52 UTC
Hi, I was the original reporter of 81084 (hey, 2.5 months and 6,000 bugs before
this one, but the older one gets marked as a duplicate, huh ?!) and the
situation isn't quite as clear cut as Brent makes out.

Firstly (and I know this sounds unusual, but it's possible), a user may not
leave their machine on for more than one hour, at least in the early days of
using a new install, so it could be weeks before "man -k" and "slocate" actually
work correctly.

Secondly, I wonder why slocate/mkwhatis are actually *daily* cron jobs anyway ?!
Does enough change on a typical system during a 24 hour period to warrant
thrashing and slowing down a system for 10-15 mins about an hour after a power on
(the delayed anacron kicking in whilst playing a game on Linux can be massively
frustrating - the system becomes very unresponsive) ?

Thirdly, let me have a stab at the help text:

Red Hat Linux optionally requires some databases to be set up in the background
to allow some commands ("slocate" and "man -k") to work correctly. Do you want to:

a) Run the database setup now (note: system will be slow for up to 30 minutes
during this setup)
b) Run the database setup later (will be run automatically after about 65
minutes and daily thereafter)
c) Never run the database setup [this will disable the cron job as well]

It's probably still a bit too techy, but it can't be far off I reckon.

On a final minor note, I keep wondering if updatedb should have an option to
"do things slowly because it's a backgrounded job" (e.g. "--slow" or something).
Maybe it puts a sleep(1); in every 1,000 files scanned or something, I dunno.
At least that way, /etc/cron.daily/slocate.cron (and makewhatis.cron/makewhatis
binary) could use that option and not hammer the system so much.

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