Post Package Update Tasks Hog System

[NoWorries]

For some time now, I have found that my system is using of the order of 100% of its CPU cycles after an update is complete. Today I measured the time this took and it was 5min 40s!

I found that the first task was packagekidt, then updates-apt-xapi came in and after this python3 completed the process. The system that I have Artful on is not very powerful, but I am puzzled why these tasks are executing so long after the completion of an update.

Am I wrong in thinking that these tasks are associated with the update process? If not, what the heck are they doing and why are they there after an update?

[whatthefunk]

I have issues with updates-apt-xapi as well. Brings my system to a crawl and I often have to kill it. Not sure what it does...

[vinnywright]

I have issues with updates-apt-xapi as well. Brings my system to a crawl and I often have to kill it. Not sure what it does...

that one updates the package information index for synaptic and apt ,,,and maybe others ,,,,it gets launched once a week as a cron job and maby as a result of updates ,,,,, you could append --update to the cron script that launches it or even remove it ,,,but you may loose some info in apt searches or show's ,,,IDK it dose not bother me so I leave it alone ,,,,,look at the script and see if it has "nice" set to "-n 19" as @ hear

#!/bin/sh

CMD=/usr/sbin/update-apt-xapian-index

# ionice should not be called in a virtual environment
# (similar to man-db cronjobs)
egrep -q '(envID|VxID):.*[1-9]' /proc/self/status || IONICE=/usr/bin/ionice

# Check if we're on battery
if which on_ac_power >/dev/null 2>&1; then
   on_ac_power >/dev/null 2>&1
   ON_BATTERY=$?

   # Here we use "-eq 1" instead of "-ne 0" because
   # on_ac_power could also return 255, which means
   # it can't tell whether we are on AC or not. In
   # that case, run update-a-x-i nevertheless.
   [ "$ON_BATTERY" -eq 1 ] && exit 0
fi

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

you can add "--update" after --quiet so it will just update the index instead of completely rebuilding it ,,,,but their must be some reason that is not the default behavior

VINNY

[NoWorries]

Sorry to say, but I have just checked the file /usr/sbin/update-apt-xapian-index on my Artful System and it does not contain the code,

   if [ -x "$IONICE" ]
  then
      nice -n 19 $IONICE -c 3 $CMD --quiet
  else
      nice -n 19 $CMD --quiet
  fi
fi

[vinnywright]

Sorry to say, but I have just checked the file /usr/sbin/update-apt-xapian-index on my Artful System and it does not contain the code,

   if [ -x "$IONICE" ]
then
    nice -n 19 $IONICE -c 3 $CMD --quiet
else
    nice -n 19 $CMD --quiet
fi
fi

no,,,no it dose not ,,,,,

you could append --update to the cron script that launches it or even remove it

and that script is in /etc/cron.weekly/apt-xapian-index ,,,,,,,,I am sure however that the program
"/usr/sbin/update-apt-xapian-index" probably gets ran by other things as well at times.

VINNY

[jlittle]

This post is based on speculation on my part. I claim no particular expertise.

IMO your problem is the result of two severe long-standing problems. I've never understood what's going on with these, only some systems are affected.

One is Heavy Disk I/O harms desktop responsiveness. 2007! That's just one of the various bugs that have been raised over the years. Changing IO schedulers can work around it; search on CFQ and deadline for discussions about that. The way it affected me was when copying GB to USB sticks; that computer was old, and it died, solving the problem for me. No amount of nicing processes will help. Most of that CPU usage is in the system flapping about rearranging virtual memory, because so many I/Os have been queued flushing code pages out, or something; I tried, but never understood.

The other is update-apt-xapian-index bogs down system. Again, that's just a representative bug report. In theory this did eventually get fixed; I'm not sure whether it is supposedly fixed in your system.

At the risk of borking your system (a backup would be a very good idea), you could try purging apt-xapian-index. Some have claimed their systems just don't need it. Some have tried installing alternative builds, but I suspect that all they achieved was installing something that crashed promptly, solving the problem. I've just run sudo apt --dry-run purge apt-xapian-index on zesty and it was going to take out muon and a couple of kubuntu components. Maybe try sudo apt install --reinstall apt-xapian-index.

[chimak111]

For some time now, I have found that my system is using of the order of 100% of its CPU cycles after an update is complete. Today I measured the time this took and it was 5min 40s!
...

Are you updating using sudo apt-get update or are you using a GUI-based method?

[claydoh]

Apt-xapian-index is not required, though I believe that Muon Package Manager may depend on it as it uses the databases for search and filtering. I do not believe that this utility is installed by default, but I have not checked.

Synaptic can live without it but filtering will not work.

I personally have not had any issues with it in some years, if ever. At least I can't recall having any problems like this.

If you don't use Muon Package Manager I'd say remove it.

Also it might be worth checking if perhaps the system is hitting the swap file at the same time as the database is updated. *buntu distros do like to utilize swap too early (and uneccesarily) sometimes, which also causes CPU spiking.


Sent from my LG-H931 using Tapatalk

[NoWorries]

Are you updating using sudo apt-get update or are you using a GUI-based method?

I have just done an update using the command line instead of Discover and that worked perfectly.

I had previously thought that using the command line or Discover gave the same problem with hogging CPU. I have made the changes suggested by vinnywrigh, so I am not sure if that solved my problem. Also, I have noticed that python3 has been updated as that was one of the trio associated with hogging CPU.

For the next lot of updates I will use Discover and see if the problem arises.

[oshunluvr]

Also it might be worth checking if perhaps the system is hitting the swap file at the same time as the database is updated. *buntu distros do like to utilize swap too early (and uneccesarily) sometimes, which also causes CPU spiking.

Totally fixable, of course.

[NoWorries]

I have just done an update using the command line instead of Discover and that worked perfectly.

I had previously thought that using the command line or Discover gave the same problem with hogging CPU. I have made the changes suggested by vinnywrigh, so I am not sure if that solved my problem. Also, I have noticed that python3 has been updated as that was one of the trio associated with hogging CPU.

For the next lot of updates I will use Discover and see if the problem arises.

This morning I had 52 updates and I used Discover and I found that updates-apt-xapi hogged the CPU for some time after Discover was exited.

[chimak111]

This morning I had 52 updates and I used Discover and I found that updates-apt-xapi hogged the CPU for some time after Discover was exited.

That's a pity because people new to Linux may prefer a GUI. I feel that Synaptic Package Manager, great as it is, isn't that "friendly" to newcomers.

IIRC, at one point, even the Baloo dev wasn't too enthused over this xapian stuff.