rawhide report: 20050417 changes

nodata fedora at nodata.co.uk
Mon Apr 18 18:20:37 UTC 2005


On Sun, 2005-04-17 at 17:35 -0400, Jeff Spaleta wrote:
> On 4/17/05, Kyrre Ness Sjobak <kyrre at solution-forge.net> wrote:
> > It can definatly be annoying for stationary systems as well, especially
> > those who isn't booted to often. Every time you try to use it, it gets
> > überslow...
> 
> Let's be clear. Having slocate updating on or not is not the real
> problem associated with bootup... the problem is anacron and anacron's
> default configuration. The reason why systems get slow on boot is
> because of anacron being configured to run the exact same things as
> the traditional cron. Bootup slowness can be prevented by changing how
> anacron is configured by default without disabling slocate database
> updating in the nightly cronscripts that run for always-on systems.
> 
> Sure, slocate is the most noticable script that runs at bootup when
> anacron is enabled... but lets face facts, most of the scripts anacron
> is configured to run by default have the ability to cause slowness
> because the end up doing disk i/o. Instead of focusing on the single
> script, anacron as a concept needs to be rethought. Is anacron serving
> any segment of the userbase well? Is anacron doing anything worthwhile
> by default for laptop users?  Take a hard look at what anacron is
> doing at bootup.. which of those scripts do you NEED to run at
> bootup..on a lappy? Is it really appropriate for anacron to be running
> logrotate? or tmpwatch? or the rpm log creation script?  These things
> aren't as intensive as slocate sure, but if the goal is get laptop
> users the best on boot experience as possible.. why is anacron really
> running any of these scripts?  Why is anacron configured by default
> with exactly the same set of tasks as traditional cron?
> 
> The default configurations of anacron and vixie-cron need to be
> separated so that on-boot activities can be tuned as needed while
> still providing always on systems with full daily script facilities.
> 
> -jef
> 

Will prelink be able to go away too?





More information about the test mailing list