updatedb.mlocate slows applications to unusable state, while running

[markor]

Binary package hint: mlocate

Every time updatedb.mlocate is running its scheduled task, it occupies hard disk and its bandwith
so user space aplications become slow and unresponsive.

Every time it runs i am mostly unable to do normal work on my machine an i need to wait
couple of minutes, doing nothing until that updatedb.mlocate thing is done.

I think that this is user-unfriendly behavior of updatedb.mlocate and I think that
it should run with some kind of lower priority to dissk, not disturbing user experience
and nor destroying Ubuntu usability for those few minutes.
I even switched time when that update runs , according to irc channel support,
and it still bugs me and destroy usability when i use computer at that time.

Current behavior: updatedb.mlocate occupies whole disk bandwith when it is run on scheduled time,
 not allowing user space applications to run and turn system in unusable state during that run.
Crucial user-space actions are affected during its run.

Wated behavior: updatedb.mlocate should run at lower priority at disk usage to avoid
blocking Ubuntu computer for the time it runs.

I run Xubuntu Hardy amd64 8.04.2/LTS

[James Troup (elmo)]

This is still a problem on jaunty; it'd be lovely if we could 'ionice -c 3' the updatedb process.

[Michael Vogt (mvo)]

Thanks for your bugreport.

This is somewhat sup suprising, this problem should be fixed in jaunty. It checks for ionice and if that is availalbe does use it. What does:
"sudo sh -x /etc/cron.daily/mlocate"
print for you?

Upon further inspection it seem like the problem is the "find" script in /etc/cron.daily that does not use ionice

[Michael Vogt (mvo)]

The problem with the /etc/cron.daily/find script should only affect people upgrading from gutsy (or earlier). Its a bit mysterious why its kept, I did a test upgrade from gutsy->hardy and there is:

Preparing to replace findutils 4.2.31-1ubuntu2 (using .../findutils_4.2.32-1ubuntu2_amd64.deb) ...^M
Removing obsolete conffile /etc/updatedb.conf ...^M
Removing obsolete conffile /etc/cron.daily/find ...^M

For hardy and later no "find" cron.daily is installed anymore.

[Michael Vogt (mvo)]

If you still have /etc/cron.daily/find on a current (jaunty) system, could you please attach it to this bugreport?

[Michael Vogt (mvo)]

@markor: if your mlocate eats all IO, could you please run:
"sudo sh -x /etc/cron.daily/mlocate"
and attach the output?

Could you also please check if you have "/etc/cron.daily/find" ?

[James Troup (elmo)]

I have a /etc/cron.daily/find; attached.

[Michael Vogt (mvo)]

Thanks for the attachment. This is the feisty version of the find cron.daily file. The gutsy one already has ionice in it.

[Michael Vogt (mvo)]

The findutils problem should be fixed now:

findutils (4.4.0-2ubuntu4) jaunty; urgency=low

  * debian/findutils.preinst:
    - remove old and obsolete /etc/cron.daily/find on upgrade
      (LP: #332790)

 -- Michael Vogt <email address hidden> Tue, 07 Apr 2009 11:04:34 +0200

[Michael Vogt (mvo)]

I close the mlocate task as well, it should be fixed with the findutils update. But please reopen if the fix is not enough (we may have two different bugs here).

[Brian Vaughan (bgvaughan)]

I'm finding updatedb.mlocate is tying up my system for a few minutes shortly after booting up in the morning.

There is no /etc/cron.daily/find on my system. I'm using Jaunty, which has been upgraded from Hardy and Intrepid.

Output of "sudo sh -x /etc/cron.daily/mlocate":

[karaluh (karaluh)]

Confirmed on karmic. sudo sh -x /etc/cron.daily/mlocate:

+ set -e
+ [ -x /usr/bin/updatedb.mlocate ]
+ which on_ac_power
+ ON_BATTERY=0
+ on_ac_power
+ ON_BATTERY=255
+ [ 255 -eq 1 ]
+ LOCKFILE=/var/lib/mlocate/daily.lock
+ trap rm -f /var/lib/mlocate/daily.lock EXIT
+ [ -e /var/lib/mlocate/daily.lock ]
+ touch /var/lib/mlocate/daily.lock
+ [ -x /usr/bin/ionice ]
+ /usr/bin/ionice -c3 true
+ IONICE=/usr/bin/ionice -c3
+ /usr/bin/ionice -c3 /usr/bin/updatedb.mlocate
+ rm -f /var/lib/mlocate/daily.lock

[Bazilio (bazilio-recast1)]

I can confirm that too
$ sudo sh -x /etc/cron.daily/mlocate
+ set -e
+ [ -x /usr/bin/updatedb.mlocate ]
+ which on_ac_power
+ ON_BATTERY=0
+ on_ac_power
+ [ 0 -eq 1 ]
+ LOCKFILE=/var/lib/mlocate/daily.lock
+ trap rm -f /var/lib/mlocate/daily.lock EXIT
+ [ -e /var/lib/mlocate/daily.lock ]
+ touch /var/lib/mlocate/daily.lock
+ [ -x /usr/bin/ionice ]
+ /usr/bin/ionice -c3 true
+ IONICE=/usr/bin/ionice -c3
+ /usr/bin/ionice -c3 /usr/bin/updatedb.mlocate
+ rm -f /var/lib/mlocate/daily.lock

4GB ram and Intel Core 2Duo T7500 on my Asus G1S. Kubuntu Karmic. Every morning I have to wait while updatedb.mlocate finish its work.

[carloslp (carloslp)]

Hello,

My system also come very slow when updatedb.mlocate is running.

Try to run it with slowest priority for the process. I added the nice parameter to /etc/cron.daily/mlocate (see it attached).

Regards

[Cruncher (ubuntu-wkresse)]

Bug #362809 mentions "high ntfs-3g IO usage". Are the people experiencing sluggishness having ntfs (=Windows) partitions?
Does io scheduling work with ntfs-3g and/or vfat?

[carloslp (carloslp)]

Nop, All my partitions are ext4. But i solved the problem running the process with slowest priority possible, with the nice parameter.

I suggest to put the parameter "nice -n 19" to all tasks in /etc/anacrontab. Or if you think this solution is not adequate at least put the "nice -n 19" in the /etc/cron.daily/mlocate as i said before.

Regards

[karaluh (karaluh)]

I also do not have any ntfs/vfat partitions mounted. And from some time now, the mlocate doesn't eat my cpu anymore.

[Bazilio (bazilio-recast1)]

Only ext4 (root) and ext3 (home) partitions. And also from some time now, the mlocate doesn't eat my cpu anymore.

[VladNistor (vladnistor)]

I am experiencing this bug in the latest Ubuntu Lucid. It doesn't eat that much cpu, but it kicks the i/o up quite a bit.

[Mike Uchima (uchima)]

I'm seeing something similar in Maverick as well.

Furthermore, when running in a VM (VirtualBox) not only does the VM itself become extremely sluggish, it also pegs one of the CPU cores on the host. To add insult to injury, it does not ignore host filesystems which have been mounted into the VirtualBox guest VM (type vboxsf); in my case, this caused updatedb.mlocate to attempt to index several hundred thousand files across multiple network file servers! Filesystem type vboxsf should probably be added to the list of ignored types in the default version of updatedb.conf...

[Greg (iskimj)]

@Michael Vogt:
The cron.daily/find script is still present in my system (Maverick now, upgraded over the years), findutils version 4.4.2-1

   $ ls /etc/cron.daily/find
   /etc/cron.daily/find
   $ dpkg -S /etc/cron.daily/find
   findutils: /etc/cron.daily/find
   $ dpkg -s findutils | grep ^Version
   Version: 4.4.2-1ubuntu1

See also: https://bugs.launchpad.net/ubuntu/+source/mlocate/+bug/197170
Sorry for cross-posting, that bug is unassigned and it's only part of the story of this report.

[Keith Hughitt (keith-hughitt)]

Confirmed on 10.10 server. System runs on ext4 but there is also a multi-terabyte XFS storage partition which is likely the cause.
I have the updatedb in cron.daily, but no find cronjob.

[Andreas E. (andreas-e)]

This is still an issue in 12.04 LTS.

[David Ordenes D. (radioboy-2)]

Also happening to me in 12.04. This might be the first time I run into this issue.
Despite the -c3 argument, I couldn't use my computer for a couple of minutes,
resulting in even more sluggishness than a long kswapd0 run.

$ sudo sh -x /etc/cron.daily/mlocate
 + set -e
 + [ -x /usr/bin/updatedb.mlocate ]
 + which on_ac_power
 + ON_BATTERY=0
 + on_ac_power
 + [ 0 -eq 1 ]
 + LOCKFILE=/var/lib/mlocate/daily.lock
 + trap rm -f /var/lib/mlocate/daily.lock EXIT
 + [ -e /var/lib/mlocate/daily.lock ]
 + touch /var/lib/mlocate/daily.lock
 + [ -x /usr/bin/ionice ]
 + /usr/bin/ionice -c3 true
 + IONICE=/usr/bin/ionice -c3
 + /usr/bin/ionice -c3 /usr/bin/updatedb.mlocate
 + rm -f /var/lib/mlocate/daily.lock

$ ls /etc/cron.daily/find
 ls: cannot access /etc/cron.daily/find: No such file or directory

[Ferran Basora (fcsonline)]

This is still an issue in 12.04 LTS.

[Tomasz (0-tomasz-u)]

This is still an issue in 13.04

[Curtis Lee Bolin (curtisleebolin)]

I filed a new bug report for this for 13.04
https://bugs.launchpad.net/ubuntu/+source/mlocate/+bug/1190696

[Guy (guy-maskall)]

ps auxw shows me the ionice'd process:
root 6466 0.0 0.0 4328 356 ? S 07:35 0:00 flock --nonblock /run/mlocate.daily.lock /usr/bin/ionice -c3 /usr/bin/updatedb.mlocate

but the problem process, blocking IO is:
root 6467 1.0 0.0 5688 2220 ? D 07:35 1:25 /usr/bin/updatedb.mlocate
It's this that eats nigh on 100% of IO. Is it a subprocess that's spawned and isn't ionice'd?