Created attachment 1018248 [details] Packages installed on one of the affected machines Description of problem: ======================= On some of my machines tracer does absolutely nothing (aka it exits almost immediately) no matter what has been just upgraded. This happens both when run as a command and as dnf plugin. Version-Release number of selected component (if applicable): ============================================================= dnf-plugins-extras-tracer-0.0.4-1.fc21.noarch tracer-0.5.8-1.fc21.noarch How reproducible: ================= Always on certain machines
Hello, thank you for the feedback. In a couple of days I will release version 0.6.0. We will see if is it better. Or could you please try upstream version? It is just git clone https://github.com/FrostyX/tracer.git sudo tracer/bin/tracer.py -ea Also, I suspect it could be related to version python-psutil package. Dont you have version 2.x on working machines and 1.x on non-working?
Hello Jakub, > Or could you please try upstream version? It is just > > git clone https://github.com/FrostyX/tracer.git > sudo tracer/bin/tracer.py -ea Got the same result with the upstream version: # yum downgrade libreoffice\* $ libreoffice --writer& $ libreoffice --calc& # yum upgrade $ time sudo tracer/bin/tracer.py -ea real 0m1.932s user 0m1.711s sys 0m0.217s > Also, I suspect it could be related to version python-psutil package. Dont > you have version 2.x on working machines and 1.x on non-working? It may be something else. I actually have Fedora21 with python-psutil-1.2.1-5.fc21.x86_64 both on the machines where tracer works as on those where it doen't.
Ok, you also could try: sudo tracer --show-resource=processes sudo tracer --show-resource=packages sudo tracer --show-resource=system to be sure that tracer can see everything that it needs to do the job.
$ sudo tracer --show-resource=processes PID Time running User Process ---------------------------------------------------------------------------------------------------- 1 1 hours root systemd [... snip uninteresting stuff ...] 7038 30 seconds davide mate-notificati 7049 1 seconds root sudo 7050 1 seconds root tracer [davide@dave ~]$ sudo tracer --show-resource=system Distribution: fedora Package Manager: Dnf, Yum Init system: systemd Uptime: 1:53:59 User: davide Tracer version: 0.5.8 Rules: 24 Applications: 47 $ sudo tracer --show-resource=packages Date Time Package name -------------------------------------------------------
Ok, so it seems that tracer doesn't know about the updated packages. Please, does the command: python -c "import sqlite3" print traceback or works fine?
Yes, it executes without errors.
Would you like access to a VM that you can test on freely?
Hmm, if you don't mind. It would be probably better, cause I wouldn't bother you with a lot of questions :-) You can send me an email and we can figure it out.
(In reply to Jakub Kadlčík from comment #8) > Hmm, if you don't mind. It would be probably better, cause I wouldn't bother > you with a lot of questions :-) > > You can send me an email and we can figure it out. This is to confirm that the VM is online and that today I sent you an email with the credentials.
Hello Jakub, I'm bringing down the VM because I'm doing some video editing and I can use the extra ram. Just ping me here if and when you need it. I'll bring it online in no time. :)
Hello, I am sorry, but I didnt get any email from you. Anyway, what kind of VM are we talking about? Maybe, can I download it from you and run it on my computer?
Hello, the VM is an almost straight copy of one of the machines affected by the malfunction so it is not exactly lean. It is about 25GB before compression. The VM is now back online. You can ssh in directly as root (at cube.blueservice.org [78.4.52.82]) Locale and keyboard are set up to en_us and you can change anything you want to your preferences. You'll find that there's MATE installed, plus a bunch of desktop stuff and third party repos. My upload link is 0.64mbps, so if you want a VM that you can download I would need to clean it up; the only problem being that I fear manipulating it too much would render the VM useless for our purpose. The email with the password was sent first from "red" to "frostyx" on "Tue, 28 Apr 2015 13:07:51 +0200" with subject '[Bug 1214961] tracer does "nothing" on some of my computers.'. I'm sending it again now, both from red and from a gmail account. Please let me know if you receive it. :)
I've examined the machine and bug was identified. Tracer was working correctly when user worked with DNF. Tracer saw all modified packages as expected. Problem occurred only with YUM (but on other machines can occur even with DNF). There was multiple sqlite databases in /var/lib/yum/history/ and tracer picked the wrong one. [root@testvm ~]# python -c "from tracer.packageManagers.yum import Yum; p=Yum(); print p._database_file()" /var/lib/yum/history/history-2014-05-07.sqlite [root@testvm ~]# ls -1 /var/lib/yum/history/*.sqlite /var/lib/yum/history/history-2014-05-07.sqlite <-- Picked /var/lib/yum/history/history-2014-10-28.sqlite /var/lib/yum/history/history-2014-12-10.sqlite <-- Should pick As said before, this issue can occur even with DNF in case it has multiple sqlite databases in /var/lib/dnf/history/ . Possible solutions: 1) Determine which sqlite database has the most recent date in its filename 2) Merge results from all of them
Since as you said the new sqlite database is created when explicitly run `yum history new`, I think that picking the last database can be good enough. Tracer still may overlook something, but how often do people rotate the history database ... Anyway, in the future it is planned to use DNF API for retrieving this informations. This issue was fixed by this upstream commit: https://github.com/FrostyX/tracer/commit/3eebd2fd1b4503a45f16b70f4d860118923c5e11 and will be released in new tracer version
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 '21'. 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 21 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 has since been fixed.