apt-check uses too much resources (starts too many processes)

Bug #746508 reported by Philip Muškovac
114
This bug affects 25 people
Affects Status Importance Assigned to Milestone
update-notifier (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: update-notifier

I have quite a few entries in my apt sources. The problem with that is that it seems like apt-check is triggered for every one of them, which is esp. an issue on slow systems as my EeePC where I end up with 22 apt-check processes, each one taking up to 50MB of memory, so every apt-get update run takes over 1GB RAM to complete. Can't apt-check run only once after apt-get update completes? Or at least run them sequentially, not in parallel?

ps auxw | grep apt-check: (after letting it run for a while)
yofel 11198 6.6 2.4 58068 50980 ? RN 16:55 0:26 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 11467 5.4 2.4 57888 50660 ? RN 16:55 0:21 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 11717 5.4 2.4 57888 50660 ? RN 16:55 0:20 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 11938 4.8 2.1 50808 43676 ? RN 16:55 0:18 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 12153 4.8 2.1 50808 43412 ? RN 16:55 0:17 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 12359 4.6 1.9 48760 41020 ? RN 16:55 0:16 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 12604 4.6 1.9 47736 40244 ? RN 16:56 0:16 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 12812 4.5 1.9 46712 39716 ? RN 16:56 0:15 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 13035 4.3 1.8 44664 37340 ? RN 16:56 0:14 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 13322 4.2 1.7 43640 36220 ? RN 16:56 0:13 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 13517 4.4 1.7 43640 36552 ? RN 16:56 0:14 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 13741 4.1 1.6 42616 34700 ? RN 16:56 0:12 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 13972 4.2 1.6 41592 34440 ? RN 16:56 0:12 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 14187 4.5 1.7 42616 35544 ? RN 16:56 0:13 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 14395 4.5 1.7 42616 34964 ? RN 16:57 0:13 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 14609 4.0 1.5 39544 31912 ? RN 16:57 0:11 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 14856 4.2 1.5 39544 32176 ? RN 16:57 0:11 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 15064 4.3 1.5 39544 32176 ? RN 16:57 0:11 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 15422 4.3 1.5 38520 31412 ? RN 16:57 0:10 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 15611 4.6 1.5 39544 32176 ? RN 16:57 0:11 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 15833 4.3 1.4 37496 30136 ? RN 16:57 0:10 /usr/bin/python /usr/lib/update-notifier/apt-check
yofel 16042 4.7 1.5 38520 31148 ? RN 16:58 0:10 /usr/bin/python /usr/lib/update-notifier/apt-check

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: update-notifier-common 0.111ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
Uname: Linux 2.6.38-7-generic i686
NonfreeKernelModules: eee
Architecture: i386
Date: Thu Mar 31 17:24:44 2011
InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
 LANGUAGE=en_US.UTF-8
SourcePackage: update-notifier
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Philip Muškovac (yofel) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in update-notifier (Ubuntu):
status: New → Confirmed
Revision history for this message
mc0e (xgcsufw02) wrote :

Loading updates from different remote hosts in parallel is useful, but it looks like there needs to be a way to switch it off.

In `man apt.conf` I see:

       Queue-Mode
           Queuing mode; Queue-Mode can be one of host or access which
           determines how APT parallelizes outgoing connections. host means
           that one connection per target host will be opened, access means
           that one connection per URI type will be opened.

Seems to me that perhaps another mode is warranted where the connections are serialised. Alternatively, perhaps a limit on the number of parallel connections in total.

Revision history for this message
Gannet (ken20001) wrote :

The same is in Wily.

Revision history for this message
Mike C. Fletcher (mcfletch) wrote :

To be clear, this bug causes the Wily machine to hard-crash with 100% CPU and 100% memory usage, forcing a hard reboot. Can't log in at console to restart, can't even get to a console to run killall. So every few days the system becomes a paper-weight and has to be converted back into a computer by human interaction...

Revision history for this message
José Luis Molina Soria (jmolina-b) wrote :

The same happens to me. After an apt-get update I have to wait long for my computer to react.

Revision history for this message
Darth Revan (darth-revan43) wrote :

Can confirm this happens on "apt-get update" command on Kubuntu 16.04. If I have more processes open when I try to run this it makes my computer unresponsive, not only because the processor is at 100% which is bad enough, but because it will start digging into swap, and I have 16GB of RAM. Terrible bug indeed!

Interestingly enough if I run "apt-get install update-notifier" it would appear as if it where not installed so it's all the more frustrating.

For those that have problems with their computer being unusable from time to time there is a file in cron.daily and cron.weekly that starts this process automatically which you can comment out. Or if you want to disable it completely you can just:

mv /usr/lib/update-notifier/apt-check /usr/lib/update-notifier/apt-check.disabled
touch apt-check
chmod 777 $_

I'm not really sure what the above would break but it's better than having the system unusable in my opinion.

Revision history for this message
pfoo (pfoo) wrote :

For kubuntu, this is related to package plasma-discover-updater

This issue seems to be resolved upstream: https://bugs.kde.org/show_bug.cgi?id=358359

Revision history for this message
Graham (gray-um) wrote :

After updating the Ubuntu servers I maintain on the 30 of September I'm having this problem too. However only on one of the servers which is currently running Ubuntu 14.04.5 LTS (3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux).

If I run apt-check manually with the following command:
# /usr/lib/update-notifier/apt-check --human-readable
0 packages can be updated.
0 updates are security updates.

It outputs quite quickly but running apt-get update tends to cause multiple processes of
'apt-check --human-readable' and causes high load.

top shows the following:
##
top - 11:00:03 up 11 days, 10:28, 1 user, load average: 28.85, 16.79, 7.03
Tasks: 279 total, 9 running, 266 sleeping, 0 stopped, 4 zombie
%Cpu(s): 20.5 us, 7.7 sy, 0.1 ni, 70.5 id, 1.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 1013868 total, 943524 used, 70344 free, 664 buffers
KiB Swap: 1046524 total, 58400 used, 988124 free. 505288 cached Mem

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15494 root 39 19 121672 34420 21224 D 4.5 3.4 0:03.18 apt-check
15650 root 39 19 121672 34260 21060 R 4.5 3.4 0:03.21 apt-check
16038 root 39 19 121676 34744 21532 D 4.5 3.4 0:03.22 apt-check
16144 root 39 19 121676 35260 22052 D 4.5 3.5 0:03.17 apt-check
16642 root 39 19 103884 28516 19756 D 4.5 2.8 0:02.48 apt-check

htop shows mostly the same but with instead of apt-check gives more info about the command:
'/usr/bin/python /usr/lib/update-notifier/apt-check --human-readable'

The server also shows more average load across the board in vSphere. CPU% has increase from normally 6% to average of 33%. However I'm not sure if this is related.

Also found a tread on serverfault with the same issue: http://serverfault.com/questions/471089/prevent-apt-check-from-eating-all-my-memory

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.