Bug 87583
| Summary: | updatedb not run after install of shrike | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | greg hosler <greg> |
| Component: | firstboot | Assignee: | Brent Fox <bfox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | chris.ricker, mitr, rkl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-03-31 17:10:14 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: | |||
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. 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. *** Bug 81084 has been marked as a duplicate of this bug. *** 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? 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. 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.
|
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: