Description of problem: Hello guys, today I noticed 100% utilization followed by each `docker run` or `docker start`. It wasn't caused by the docker itself, but with each instance, yumBackend is executed. It never happened with older version. 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Version-Release number of selected component (if applicable): docker-io-1.0.0-1.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -t -i fedora bash 2. top 3. ps ax |grep yum Actual results: yumBackend is started and takes couple of secconds in 100% utilization 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Expected results: Apart from container no other processes should be started. (I can run `docker run -t -i fedora bash -c exit` which finishes immediately and the only process using cpu is the yumBackend process) Additional info: I tried executing `busybox sh`, `bash -c exit`, .... I even rebooted the machine but the results are the same.
I have no idea why. I don't there is any communications between docker daemon and yum backend.
Lukas, this doesn't seem to occur with 1.1.2 anymore. Could you verify this please?
Hi Lokesh, it's probably system-dependant, because I still see this failure and it annoys me. After a while of spawning and removing containers I end up with 100% utilization which takes hours to finish. My /var/log/messages is full of: Sep 5 10:18:47 t530 PackageKit: update-packages transaction /46549_daebdbbc from uid 1000 finished with success after 3999ms Sep 5 10:18:51 t530 PackageKit: update-packages transaction /46550_cdeacbdb from uid 1000 finished with success after 3951ms Sep 5 10:18:55 t530 PackageKit: update-packages transaction /46551_ecdabbbc from uid 1000 finished with success after 4399ms Sep 5 10:18:59 t530 PackageKit: update-packages transaction /46552_ccdcaedd from uid 1000 finished with success after 3992ms Sep 5 10:19:03 t530 PackageKit: update-packages transaction /46553_bedacbcd from uid 1000 finished with success after 3986ms Sep 5 10:19:07 t530 PackageKit: update-packages transaction /46554_ecaddbac from uid 1000 finished with success after 4011ms Sep 5 10:19:11 t530 PackageKit: update-packages transaction /46555_dbecccce from uid 1000 finished with success after 3937ms Right now I'm using docker-io-1.2.0-2.fc20.x86_64. Good thing is that when I execute `yum clean all` it stops. Anyway once I start another container. Do you know any method to see what asked for this yumBackend?
Is this a generic container? IE Does this happen for other container images besides Fedora?
Hi Daniel, it's not related to the image. I can use busybox as well. Also simple `docker pull busybox:latest` also generates multiple `update-packages` transactions. (starting after the first layer is downloaded, so probably one per each image layer). I also tried clean installation (and couple of setting, program installation, ...) of Fedora 20 (the same I have) and the problem was not there. So either you have to have specific programs installed or configuration set or just run long enough... Dan, is there a way to trace who asks for the update-packages?
PackageKit guys, do you have any idea what could cause this?
I would guess that *something* is talking to PackageKit via dbus. Hard to tell what that "something" is yet, without more extensive logging here. Probably depends on what is in the docker image and what it is doing (anything yet?). things off the top of my head that can hit PackageKit include: PackageKit-command-not-found apper/gnome-packagekit auto codec/font/printer-driver installs Offhand, it may be best to simply omit PackageKit from your docker image too, as I doubt any of those things would be very useful.
Hmm, PackageKit isn't present in the fedora image (not sure about the other images though) bash-4.2# rpm -q PackageKit package PackageKit is not installed
ok, maybe I'm confused. I assumed PackageKit was running inside the docker image. Reporter, can you clarify (and mention which docker images you used specifically that exhibits this problem)?
Hi guys, it's the host machine, which is running the PackageKit. Containers are just sitting there waiting for any command (as written before, the same behavior for busybox image or even `docker pull ...` which - if I'm not mistaken - doesn't run any containers).
Created attachment 936228 [details] dbus-monitor --system output This is the `dbus-monitor --system` output. After the monitor started I executed `docker run -t -i busybox bash`, which initiated yumBackend in host and lead to 100% utilization of the host machine.
I see I didn't attach the yumBackend cmdline which is executed: 8449 ? RN 0:01 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py update-packages only-trusted;only-download qemu-user;2:1.6.2-10.fc20;x86_64;updates&libreoffice-pdfimport;1:4.2.7.2-4.fc20;x86_64;updates&qemu-system-arm;2:1.6.2-10.fc20;x86_64;updates&qemu-img;2:1.6.2-10.fc20;x86_64;updates&ibus-gtk2;1.5.9-4.fc20;x86_64;updates&autocorr-cs;1:4.2.7.2-4.fc20;noarch;updates&firebird-libfbembed;2.5.2.26539.0-9.fc20;x86_64;updates&teamd;1.13-1.fc20;x86_64;updates&perl-Package-Constants;1:0.02-291.fc20;noarch;updates&python3-libs;3.3.2-18.fc20;x86_64;updates&qemu-system-moxie;2:1.6.2-10.fc20;x86_64;updates&libreoffice-core;1:4.2.7.2-4.fc20;x86_64;updates&chkconfig;1.3.63-1.fc20;x86_64;updates&qemu-system-ppc;2:1.6.2-10.fc20;x86_64;updates&qemu-system-s390x;2:1.6.2-10.fc20;x86_64;updates&libreoffice-opensymbol-fonts;1:4.2.7.2-4.fc20;noarch;updates&python3;3.3.2-18.fc20;x86_64;updates&qemu-system-mips;2:1.6.2-10.fc20;x86_64;updates&google-noto-sans-mandaic-fonts;20141001-2.fc20;noarch;updates&qemu-system-lm32;2:1.6.2-10.fc20;x86_64;updates&perl;4:5.18.4-291.fc20;x86_64;updates&google-noto-sans-lisu-fonts;20141001-2.fc20;noarch;updates&libteam;1.13-1.fc20;x86_64;updates&libreoffice-writer;1:4.2.7.2-4.fc20;x86_64;updates&libreoffice-graphicfilter;1:4.2.7.2-4.fc20;x86_64;updates&hdparm;9.45-1.fc20;x86_64;updates&libreoffice-pyuno;1:4.2.7.2-4.fc20;x86_64;updates&ntsysv;1.3.63-1.fc20;x86_64;updates&libreoffice-calc;1:4.2.7.2-4.fc20;x86_64;updates&perl-libs;4:5.18.4-291.fc20;x86_64;updates&qemu-system-x86;2:1.6.2-10.fc20;x86_64;updates&qemu-guest-agent;2:1.6.2-10.fc20;x86_64;updates&audit-libs;2.4.1-1.fc20;x86_64;updates&qemu-system-sh4;2:1.6.2-10.fc20;x86_64;updates&libreoffice-emailmerge;1:4.2.7.2-4.fc20;x86_64;updates&firebird-libfbclient;2.5.2.26539.0-9.fc20;x86_64;updates&unzip;6.0-13.fc20;x86_64;updates&python-devel;2.7.5-15.fc20;x86_64;updates&qemu-system-or32;2:1.6.2-10.fc20;x86_64;updates&libreoffice-ure;1:4.2.7.2-4.fc20;x86_64;updates&libcurl;7.32.0-15.fc20;x86_64;updates&libreoffice-math;1:4.2.7.2-4.fc20;x86_64;updates&perl-ExtUtils-Install;1.59-291.fc20;noarch;updates&qemu-system-microblaze;2:1.6.2-10.fc20;x86_64;updates&audit-libs-python;2.4.1-1.fc20;x86_64;updates&perl-Module-CoreList;1:3.13-291.fc20;noarch;updates&curl;7.32.0-15.fc20;x86_64;updates&perl-macros;4:5.18.4-291.fc20;x86_64;updates&perl-Pod-Escapes;1:1.04-291.fc20;noarch;updates&libreoffice-impress;1:4.2.7.2-4.fc20;x86_64;updates&docker;1.5-10.fc20;x86_64;fedora&libpurple;2.10.10-1.fc20;x86_64;updates&google-noto-sans-tai-viet-fonts;20141001-2.fc20;noarch;updates&ibus-setup;1.5.9-4.fc20;noarch;updates&perl-devel;4:5.18.4-291.fc20;x86_64;updates&python-libs;2.7.5-15.fc20;x86_64;updates&qemu-system-sparc;2:1.6.2-10.fc20;x86_64;updates&tkinter;2.7.5-15.fc20;x86_64;updates&qemu-system-cris;2:1.6.2-10.fc20;x86_64;updates&qemu-common;2:1.6.2-10.fc20;x86_64;updates&libcacard;2:1.6.2-10.fc20;x86_64;updates&autocorr-en;1:4.2.7.2-4.fc20;noarch;updates&qemu-system-unicore32;2:1.6.2-10.fc20;x86_64;updates&qemu-system-m68k;2:1.6.2-10.fc20;x86_64;updates&ibus-libs;1.5.9-4.fc20;x86_64;updates&libreoffice-draw;1:4.2.7.2-4.fc20;x86_64;updates&audit-libs;2.4.1-1.fc20;i686;updates&audit;2.4.1-1.fc20;x86_64;updates&qemu-system-xtensa;2:1.6.2-10.fc20;x86_64;updates&ibus-gtk3;1.5.9-4.fc20;x86_64;updates&python;2.7.5-15.fc20;x86_64;updates&ibus-wayland;1.5.9-4.fc20;x86_64;updates&libreoffice-langpack-cs;1:4.2.7.2-4.fc20;x86_64;updates&virt-manager-common;1.0.1-5.fc20;noarch;updates&google-noto-sans-meeteimayek-fonts;20141001-2.fc20;noarch;updates&qemu-system-alpha;2:1.6.2-10.fc20;x86_64;updates&google-noto-sans-tagalog-fonts;20141001-2.fc20;noarch;updates&google-noto-sans-tai-tham-fonts;20141001-2.fc20;noarch;updates&selinux-policy-targeted;3.12.1-193.fc20;noarch;updates&virt-manager;1.0.1-5.fc20;noarch;updates&qemu;2:1.6.2-10.fc20;x86_64;updates&ibus;1.5.9-4.fc20;x86_64;updates&qemu-kvm;2:1.6.2-10.fc20;x86_64;updates&selinux-policy;3.12.1-193.fc20;noarch;updates&perl-IO-Zlib;1:1.10-291.fc20;noarch;updates&device-mapper-persistent-data;0.4.1-1.fc20;x86_64;updates I hope it will help, although I haven't seen this error on any other systems but mine...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is fixed in F21+ where PackageKit uses the hif backend instead of yum.