laptops and cron maintenance

Mike A. Harris mharris at www.linux.org.uk
Wed Apr 20 07:09:51 UTC 2005


Michal Jaegermann wrote:
> On Tue, Apr 19, 2005 at 01:10:21PM +0200, Miloslav Trmac wrote:
> 
>>AFAIK it was turned off because "desktop users" don't use locate,

Re. to mitr:
That isn't why it was turned off at all, from my recollection.

The updatedb cron job grinds any modern machine to a screeching
halt when it kicks in.  This makes my machine totally useless for
anywhere from 3-10 minutes, at which point prelink then seems to
occasionally kick in and makes it useless for many more minutes.

This problem affects many users.  I'm not sure what the best solution
to the problem is, but having this happen on a laptop must be
horrible.  ( I don't have a laptop so am going by opinions of
others who do.)

My understanding is that it was disabled due to desktop
interactivity problems such as those myself and many others
experience when updatedb kicks in.  Saying "desktop users do
not use locate" is absurd for several reasons:

1) It's simply not true
2) Our OS is used by hobbiests, enthusiasts, server admins,
    and a variety of other usage cases which include "desktop"
    users ranging from "engineering desktop/workstation" to
    "corporate desktop" to "home desktop (to a lesser extent)".


> Eh?  How this gem of information was derived?  This definitely
> does not mesh up with what I am seeing and I am not talking about
> myself.  Sure, this is anecdotal and not statistical.

Agreed.

> This will likely become a self-fulfilling prophecy as with locate
> turned by default effectively off a percentage of using it will
> surely go down.

I think we can derive some useful facts about locate:

1) It's widely used by our userbase
2) When updatedb kicks in, it causes interactivity problems, which
    affect people using a GUI desktop (regardless of the class of
    user using the desktop, be they technical or be they Grandma)

The problem to solve, is basically:

- What different approaches might there be to solving this problem
   and both keeping "locate" available by default, and also reducing
   or eliminating the horrible interactivity problem that occurs when
   updatedb runs?

There are many possible solutions in theory.

- Disable updatedb from running by default.  This isn't a solution,
   it is simply avoiding the problem from happening by default by
   making locate unuseable by default.  It just inconveniences users
   who do still want locate to work, who now have to re-enable it
   and then still end up with the interactivity problem.  Bad
   resolution.

- Perhaps alter updatedb's script to use iorenice to lower it's
   I/O priority and improve interactivity?  Not sure if this would
   actually result in the desired behaviour or not, but I'm sure
   one of our kernel guys can advise wether this would truly help
   or not.

- Enhance updatedb so that it only kicks in if the machine has
   been idle for so long (keyboard/mouse) kindof like a screensaver.
   If someone presses a key or moves the mouse, it's sent a signal
   to stop or something.  This suggestion is unrefined but can be
   potentially a basis for further ideas/discussion.

- Turn updatedb into a daemon which updates the database by using
   fam/gamin to get directory notification events.  Not sure how
   feasible or crackrock this might be, but it popped into my mind,
   and if it is feasible, and any problems it might have could be
   worked out, might make locate even more useful.

- Explore possible alternatives to updatedb which are friendlier
   to the system (if there are any).

I'm sure others might have additional suggestions.  Feel free
to comment on mine.




More information about the test mailing list