Resource Hog: update-apt-xapi

[GuiGuy]

I see a process update-apt-xapi that brings my system to an unusable state each morning

update-apt-xapi

Shades of Windows!

Is this thing really necessary, or can I

sudo apt-get autoremove --purge apt-xapian-index
sudo apt-get autoremove --purge

without breaking something else?

NB: It has been suggested this problem occurs on low resource system only. Wrong; my PC is high end, dual core, 4G RAM.

Thanks

[zvacet]

You can go to the synaptic and find that package and lock version.That way it will be no more upgraded.You can also

sudo aptitude hold package_name

[GuiGuy]

You can go to the synaptic and find that package and lock version.That way it will be no more upgraded.You can also

sudo aptitude hold package_name

Thanks

[fcormier]

I have the same issue, but my system is rather old (P3 with 256 MB of RAM) and running Xubuntu.

Here is what I did to disable it:

sudo chmod 644 /etc/cron.weekly/apt-xapian-index

It makes the file not executable.

[ashmew2]

Was having the same issue , Jaunty 32 Bit, this site helped : http://reformedmusings.wordpress.com...u-9-04-jaunty/

Thanks to the person who wrote it!!

[alias_knagg]

Nice enough tale, but why not just "nice" it?

in /etc/cron.weekly/apt-xapian-index

Change

$CMD --quiet

to

nice -n20 $CMD --quiet

[klausner]

Nice enough tale, but why not just "nice" it?

in /etc/cron.weekly/apt-xapian-index

Change

$CMD --quiet

to

nice -n20 $CMD --quiet

I thought the highest positive value for nice was 19.

[Eiríkr]

Hallelujah, a Fix!

For anyone else bitten by this bug, the Launchpad discussion makes it clear that a fix exists and will be incorporated into Ubuntu at some point. For those impatient to get the fix working now, this post from the Launchpad thread includes the following:

#!/bin/sh

CMD=/usr/sbin/update-apt-xapian-index
IONICE=/usr/bin/ionice

# Rebuild the index
if [ -x $CMD ]
then
	if [ -x $IONICE ]
	then
		nice -n 19 $IONICE -c 3 $CMD --update --quiet
	else
		nice -n 19 $CMD --update --quiet
	fi
fi

Fire up your favorite text editor with sudo, open the /etc/cron.weekly/apt-xapian-index file, and edit the contents to match the above.

What This Does

update-apt-xapian-index helps maintain an index of packages, and this helps speed up searching for packages in Synaptic, and possibly in other package managers as well.

cron is a utility for scheduling tasks to run at certain times. System tasks run weekly are, unsurprisingly, stored in the /etc/cron.weekly directory. You can also set up personal tasks to run pretty much whenever you want. For that, have a look at man crontab.

Looking at the internals of the code we're using here, the first line, the "crunchbang" line (#!), tells the system what executable to use to run the contents -- in this case, /bin/sh, or your basic shell.

The next two lines establish two shorthand variables. Variables in shell scripts are generally defined in ALL CAPS for easy readability. This is more of a best practice than any hard-and-fast requirement. When referenced later in the script, the variable names are prefixed with a $. Here, CMD is simply shorthand for the path to the update-apt-xapian-index binary, and IONICE is shorthand for the path to the ionice utility for getting or setting a process's I/O scheduling class and priority.

In the if statements, the -x checks to see if the next argument exists, so if [ -x $CMD ] will check to see if /usr/sbin/update-apt-xapian-index exists in the filesystem.

nice -n is basically how you assign a priority to a process. An important caveat, however, is that nice is just that -- a high nice value (up to a maximum of -n 19) means the process is nice and gets out of the way, and a low nice value (down to a minimum of -n -20) means the process is *not* nice and barges to the front of the line to be the first to use system resources. Niceness defaults to 10 if not otherwise specified, and apparently the default update-apt-xapian-index setup does not specify any value.

ionice is new in this fix. It works along similar lines, affecting a process's input/output niceness, only using the flag -c for "class". The ionice man page describes -c:

-c class
The scheduling class. 0 for none, 1 for real time, 2 for best-effort, 3 for idle.

Finally, we have the two options passed to update-apt-xapian-index itself, --update and --quiet. --quiet just tells it to not generate much text, only outputting for fatal errors, which makes sense for a background process. --update is new here in this fix together with the nice value and the ionice prioritization, and is a real kicker: it tells update-apt-xapian-index to only update those items in the index that have actually changed. This seems like a no-brainer, since the index includes *every* package installed in the system, but unfortunately the default update-apt-xapian-index setup in a fresh install of Jaunty, Karmic, or Lucid all leave this option out, meaning that update-apt-xapian-index will rebuild the ENTIRE package index every time it runs. No wonder it eats up so much memory and CPU time! With --update, it should take much less resources and much less time.

----------

Hope this helps, folks!

Cheers,

-- Eiríkr

[pete_m]

Hello ErikR -
Thanks for your script - ran it successfully and the size of xapi/index1 came down by more than 20Mb.
However - the 2 big files . .termlist.DB and postlist.DB still occupy more than 90Mb.

I'm trying to keep everything including a modest /home on a single partition of 4Gb in the interest of making USB sticks of this size or less.

Under what circumstances would it be possible to zap these 2 files ?
perhaps when no apt work is anticipated immediately prior to preparing .iso images.
or . .

Any help with this and the related issue of minimizing disk usage would be much appreciated.


I'm an EEE PC user planning an imminent move from Karmic to Lucid . .
in the hope of performance improvements and the benefit of tieing in to a fresh LTS release.

i've put some work into my existing Ubuntu install based on 9.10 karmic nbr2 and am very happy with the results - full credit and thanks to all

First screenshots - more soon - of my work in progress at

http://www.youtube.com/watch?v=YoI4wRVVjBs


P.S.
if anyone reading this knows how & when it is possible to create 'live' USB's with persistent storage from .iso images prepared with remastersys
i just started a thread about this .. http://ubuntuforums.org/showthread.php?t=1484555

[scared0o0rabbit]

Tagging so that I can easily find this later on.