multiple scrollkeeper-update makes apt upgrade very slow

Yes, I agree. I often have to wait a long time for scrollkeeper to run.

I read that scrollkeeper is unmaintained and there is a project to replace it named 'spoon'.

http://live.gnome.org/Yelp/Spoon

Thanks for the Spoon hint. But it seems that that project will still take some time to replace scrollkeeper.

So as my laptop is (yet again) being stuck during an update, and two scrollkeeper-update processes are burning all CPU cycles, I'm wondering if it's possible to completely disable scrollkeeper on my machine? I don't use the Gnome doc anyway, so it wouldn't matter for me. Any ideas from the devs?

Marking as confirmed, scrollkeeper may very well take minutes even on a fast machine, and when installing Ubuntu on a slow machine it can take even an hour (!).

Btw. as I haven't noticed any advantage from having scrollkeeper running, it is currently disabled here, by moving /usr/bin/scrollkeeper-update away and instead creating a "dummy" symlink instead, with:
ln -s /bin/true /usr/bin/scrollkeeper-update

Works fine so far :-)

Yes, scrollkeeper is so slow I thought it was broken! I've been killing it during upgrades so that they can complete. This is on a group of 550-650 mhz PIIIs.

Looks like 'spoon' has been superseded since I last posted.

I found this wiki page https://wiki.ubuntu.com/UseTheSpoon which looks like spoon was/is being considered - perhaps a dev could take a look at http://rarian.freedesktop.org/ ?

I did this ln -s /bin/true trick as well.

Just to echo what the others said, especially on old hardware scrollkeeper takes waaaaay longer than it should have to. Since I don't use yelp at all, my solution was a bit more comprehensive:

sudo dpkg -P yelp ; cd /usr/bin ; sudo mv scrollkeeper-update scrollkeeper-update.REAL ; sudo ln -s /bin/true scrollkeeper-update ; sudo find /var/lib/scrollkeeper/ -name \*.xml -type f -exec rm -f '{}' \;

The link to the spoon has moved:
https://wiki.ubuntu.com/Spec/UseTheSpoon

But it's old enough now that it has me wondering if a different solution altogether needs to be cooked up.

Uninstalling yelp sounds somewhat "bad" to me as several packages depend on it :-)
But if you feel adventurous, you could try installing the rarian-compat package which is listed as an alternative for scrollkeeper. The Gnome people already list it as a build requirement (see http://live.gnome.org/TwoPointNineteen/ExternalDependencies?highlight=%28rarian%29) but probably the Ubuntu devs want to give it more testing first. No idea how stable it is in reality, though.

please get this upgraded from wishlist status... scrollkeeper-update is making updates take a ridiculously long time. it needs modifying so that it only runs at the end of the update/upgrade and with the lowest priority possible...

This bug should be marked high, I can't stand waiting 90+ minutes for this to finish. I have a Pentium III machine and this well spoils my ubuntu experience, I have to do sudo kilall scrollkeeper-update all the time. Please remove this unwanted keeper away from ubuntu or we will lose the low-end market forever.

When i'm running large upgrades i just open another terminal and type:

$ watch -n 5 sudo killall scrollkeeper-update

This effectively keeps the scrollkeeper death from slowing the upgrade.

For the love of all that's beautiful and holy in this world, please get rid of scrollkeeper! I have a 3.2GHz quad core CPU and it still runs for > 3 minutes! On my poor little PowerPC G3 scrollkeeper ran for hours until the battery finally died. It's a blight on the Ubuntu experience.

I just got a ubuntu-docs update and got hit my scrollkeeper. I don't use any docs at all except "man" and "google", I certainly don't want to wait for this stuff to finish and I agree with previous posters that it should run with low priority after all updates are finished. I have a *VERY* fast multicore machine and I was annoyed by scrollkeeper-update because; for some reason it insists on running on a *single* core meaning that it only uses a tiny fraction of my machine. This is silly for a job that is clearly highly CPU intensive (and which probably would be fairly easy to parallelize).

As an interim solution, how about using a dpkg trigger to at least only run scrollkeeper-update once per upgrade/install run?

I'll have a look at cooking up a patch for this over the weekend.

Attached is a debdiff which implements the trigger. scrollkeeper-update will still be run twice if both scrollkeeper and some scrollkeeper-using package are upgraded at the same time, since scrollkeeper-rebuilddb calls scrollkeeper-update, but I didn't want to risk breaking anything in case scrollkeeper-rebuilddb starts relying on doing something after scrollkeeper-update has finished.

This kills ps3 ubuntu badly during a recent update. It is dissapointing that it cannot be uninstalled without excessive side-effects.

Please just patch it out of existence or fudge the dependencies so it can be safely ignored.

thx ski for the work around.

Another thing to mention: scrollkeeper-update does also take a lot of memory causing my laptop to swap and slow down.

Scrollkeeper has been superseded by librarian in intrepid, so this should be fixed now? Probably the trigger thing would be good for it, too.

I don't believe it has been fixed, according to https://help.launchpad.net/Bugs/Statuses

Could we get librarian in Hardy? The high CPU is absolutely ridiculous - it is a bug that should be addressed.

scrollkeeper has been removed from the development release of Ubuntu and is not being maintained. Further bug fixing is extremely unlikely.

scrollkeeper is still present and used in Ubuntu netbook remix 9.04, and it still is very slow.
Please do something to fix the problem.

In 9.04 you can replace scrollkeeper with librarian which should fix your problems. It's so easy, I'm not sure why they didn't do it before.