Created attachment 1349121 [details] log of dnfdragora started from a terminal Description of problem: When launching dnfdragora-gui from the dash, I get this error message box: >>> dnfdaemon client error occured: >>> g-io-error-quark: >>> GDBUS.Error:org.baseurl.DnfSystem.LockedError: dnf is locked by another >>> application (36) dnfdragora-gui closes when ACKing this message box Version-Release number of selected component (if applicable): Fedora 27 (beta), up-to-date dnfdragora-gui-1.0.1-6.git20170505.2a3b056.fc27.noarch How reproducible: Almost every time. I tried about 100 times and got it working about 3 times Steps to Reproduce: 1. Run dnfdragora from dash Actual results: dnfdragora shows an error message and closes Expected results: dnfdragora runs normally Additional info: I don't think that dnf is locked by another application. In a terminal, when I type "$ dnf upgrade", it works. Just after that, I try to run dnfdragora, and it fails as described above. Then I re-type "$ dnf upgrade" in the terminal, and it works again. So I don't think there is really a locker taken by another application.
does that happen also the first time you run it? or just after the first running? In the second case could you run it from a console and paste here the output on exit?
Honestly, I can't remembrer if it happens first time (ie: right after dnfdragora gui installation). Log from console is already attached: https://bugzilla.redhat.com/attachment.cgi?id=1349121
yes that is when it finds dnfdaemon locked, but that could be right, what i need is understanding if was dnfdragora itself to leaving locked the db
Created attachment 1350934 [details] log of dnfdragora started from a terminal
I did: - uninstall dnfdragora/dnfdragora-gui - reboot - re-installed dnfdragora-gui At launch, I get this error message: https://bugzilla.redhat.com/attachment.cgi?id=1350934 Few seconds later, my system freezes, need to hard reboot. After the hard reboot, I get the same error message at launch, but the system doesn't crash anymore. As a consequence, I can't get anymore a dnfdragora gui. I did this procedure twice, and got the same result every time. Thanks for your attention.
Could it be that it's a PackageKit updater (GNOME Software or plasma-pk-updates) locking the DNF database? (By the way, the default shell in Fedora is bash, not dash.)
The reporter clarified that he meant the dashboard, not the shell called dash.
I just encountered this same error on a fresh install of Fedora 27. I noticed that the generated bug report for it showed a failed Python init call. I grepped for "dnfdaemon" and indeed it was still running under root called by python3 (/usr/bin/python3 /usr/share/dnfdaemon/dnfdaemon-system). I killed it, and started dnfdragora and it started fine. I suspect having randomly seen a curl command in the generated bug report, that because I wasn't connected to the internet, an initialization step in the Python script that required network connectivity run by dnfdragora failed, and hung, leaving that process hanging. Unfortunately I haven't been able to replicate the error since, so can't actually view the details again.
dnfdaemon-0.3.18-5.fc27 dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d66bd84f06
dnfdaemon-0.3.18-5.fc26 dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8caadb4a1b
dnfdaemon-0.3.18-5.fc27, dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d66bd84f06
dnfdaemon-0.3.18-5.fc26, dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8caadb4a1b
dnfdaemon-0.3.18-5.fc27, dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
dnfdaemon-0.3.18-5.fc26, dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
The problem still exists (Fedora 27).
Well dnfdragora is not yet single instance program, it will be. So yes if you run dnfdragora from menu or terminal and then you run also from dnfdragora updater menu is still persist. In any case if you for any reasons get a crash that does not close it correctly you can force dnfdaemon to be closed by using *dnfdragora --exit*
(In reply to Angelo Naselli from comment #16) > Well dnfdragora is not yet single instance program, it will be. So yes if > you run dnfdragora from menu or terminal and then you run also from > dnfdragora updater menu is still persist. > > In any case if you for any reasons get a crash that does not close it > correctly you can force dnfdaemon to be closed by using *dnfdragora --exit* I was receiving this error even from a cold boot. I checked System Monitor and killed all instances of dnfdragora. I ended up just uninstalling it and using rpm from the command line.
Maybe you could give me some more information instead, since i cannot replicate it :(
I don't have the power to reopen this bug, i was able at last to reproduce it, just reducing updater time to check and updating the system. Last commit on github should fix it. I'll attach a patch here to for convenience.
Created attachment 1377055 [details] Patch that fixes bad closure on exception
Thanks! Reopening.
Ping? Can you please apply this patch and also fix bug #1531118?
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca49003128
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ff5c89f68a
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ff5c89f68a
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca49003128
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
dnfdragora-1.0.1-9.git20180108.b0e8a66.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Hello Guys. Here is a SOLUTION; its stupid but it works - Select Applications Menu (Top Left Corner). - Select Administration > dnfdragora-updater - Software Management Icon (Yellow Cuboid)appears next to the clock on the Top Right corner. - Right Click (Ctrl Click) on the Yellow Cuboid (Icon). - Then select Open dnfdragora dialogue (the application freezes at this point.Give it a couple of seconds or a minute). - Right Click (Ctrl Click) the Yellow Cuboid (Icon) again. - Select Exit. - Go back to the Applications Menu (Top Left Corner). - Select Administration > dnfdragora (Not the updater). - Software Management opens successfully (Give it some time to load software Updates) Test the application by typing something like Tor Browser (Make sure the search filters are set to All > All > In Summaries) then click Search. Thank.
Thank you.
Fedora 27 dnfdragora versio 1.0.1-9.git20180108.b0e8a66.fc27 dnfdragora-updater version1.0.1-9.git20180108.b0e8a66.fc27 After lunch dnfdragora client 'I have obtained message "dnfdaemon client error occured: g-io-error-quark: GDBUS.Error:org.baseurl.DnfSystem.LockedError: dnf is locked by another >>> application (36)' I stoped service dnfdaemon, started dnfdragora, started service dnfdaemon an d client worked normaly (without any error, read all packeges to update).
(In reply to Marian Adamjak from comment #31) > Fedora 27 > dnfdragora versio 1.0.1-9.git20180108.b0e8a66.fc27 > dnfdragora-updater version1.0.1-9.git20180108.b0e8a66.fc27 > > After lunch dnfdragora client 'I have obtained message "dnfdaemon client > error occured: g-io-error-quark: > GDBUS.Error:org.baseurl.DnfSystem.LockedError: dnf is locked by another >>> > application (36)' > > I stoped service dnfdaemon, started dnfdragora, started service dnfdaemon an > d client worked normaly (without any error, read all packeges to update). Fedora 28. Exact same error message. "g-io-error-quark: GDBus.Error:org.baseurl.DnfSystem.LockedError: dnf is locked by another application (36)" > [justina@blanco ~]$ dnf list installed "dnf*" > Installed Packages > dnf.noarch 2.7.5-12.fc28 @anaconda > dnf-conf.noarch 2.7.5-12.fc28 @anaconda > dnf-plugins-core.noarch 2.1.5-4.fc28 @anaconda > dnf-yum.noarch 2.7.5-12.fc28 @anaconda > dnfdaemon.noarch 0.3.18-6.fc28 @anaconda > dnfdaemon-selinux.noarch 0.3.18-6.fc28 @anaconda > dnfdragora.noarch 1.0.1-10.git20180108.b0e8a66.fc28 @anaconda > dnfdragora-updater.noarch 1.0.1-10.git20180108.b0e8a66.fc28 @anaconda > [justina@blanco ~]$ Looking at the those installed packages, I see something about selinux. It looks like a policy issue, so I would not hesitate to do this: > [root@blanco ~]# touch /.autorelabel && reboot Sometimes these packages are not installed or committed to the repositories "exactly" in sync with their respective selinux policies, and certain obscure and difficult-to-diagnose permissions issues arise, but let me tell you, SELinux is worth it.
(In reply to justinacolmena from comment #32) That worked. Sorry to post about it before I tried it, but that was indeed the problem for me. I would like to see more "auditing" on some of those SELinux permission denials, because the errors thrown by those denials tend to come across as low-level operating system or hardware access permission errors, which are difficult for applications, not written to be SELinux-aware, to interpret.
I recommend just disabling SELinux, all it can ever do by design is break things, and it is not even always obvious that is SELinux that is breaking your system. (In this case, it took 6 months for somebody to find this out!)
It wasn't an SELinux problem at all; see comment #33. SELinux is excellent if used properly. You can always set it to Permissive mode (setenforce Permissive) to get error messages but still allow your apps to continue. But it's certainly of value to know how and when (and why) your apps are not playing nicely with others.
SELinux made it fail, it would have worked fine if SELinux had been disabled, so it is an SELinux problem. (And we have not figured out how the labels got messed up in the first place, only that relabeling fixed it. So I suspect a bug in either SELinux itself or the SELinux policy to have caused the mislabeling.)
I can confirm that this issue is still present in the current Fedora 28 Xfce spin. Hopefully this can be addressed. For a new user this is quite inconvenient. He can choose to disable dnfdragora-updater but then won't receive any new updates notification. As a workaround I created a cron rule to run dnfdragora --exit every hour.
I can confirm that this issue is still present in the current Fedora 29 after a fresh upgrade from FC27; -reinstalling dnfdragora doesn't help; - touch /.autorelabel && reboot doesn't help; moreover I had to remove the /var/lib/dnf/history to solve a parallel problem of a missing table that deny dnf working, maybe those issues are related? File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main return cli_run(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 760, in resolve self._transaction = self._goal2transaction(goal) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 681, in _goal2transaction ts.add_upgrade(pkg, upgraded, obs) File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 269, in add_upgrade ti_new = self.new(new, libdnf.transaction.TransactionItemAction_UPGRADE) File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 219, in new rpm_item = self._pkg_to_swdb_rpm_item(pkg) File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 210, in _pkg_to_swdb_rpm_item rpm_item = self.history.swdb.createRPMItem() File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: Exec failed: no such table: main.trans_cmdline During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 121, in __exit__ self.close() File "/usr/lib/python3.7/site-packages/dnf/base.py", line 472, in close self._finalize_base() File "/usr/lib/python3.7/site-packages/dnf/base.py", line 455, in _finalize_base self.history.close() File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 305, in close self.swdb.closeTransaction() File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: Exec failed: no such table: main.trans_cmdline
I tried to adjust the columns of the main sub-window, but when one column accidentally got zero width, dnfdagora crashed. Now I am getting the same error above every time try to run dnfdragora. I cannot find an "Administration" item in the "Applications" menu, as suggested in this comment https://bugzilla.redhat.com/show_bug.cgi?id=1510632#c29 Maybe because I am using the MATE desktop? Yum does not work anymore ("error in yum transaction : invalid version flag:"), and now dnfdragora is kaputt... Anyway, is there some file somewhere that I can remove by hand to break this stupid lock? Please? I see that this bug has been pending for 18 months now...
I have found my own workaround to circumvent the problem by adding the following two lines to `crontab -e`: 0 * * * * dnfdragora --exit && killall dnfdragora-updater 5 */6 * * * export DISPLAY=:0 && dnfdragora-updater This prevents the above error and shows a tray icon when new updates become available. Works perfectly on Fedora 30 Xfce! :)
This bug still exists in 1.1.1. Where is the source code? I'd like to look at it. Why does this bug keep returning?