Bug 1510632 - dnfdragora keeps saying "dnf is locked by another application" while dnf can be used in a terminal
Summary: dnfdragora keeps saying "dnf is locked by another application" while dnf can ...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnfdragora
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Björn 'besser82' Esser
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-07 21:03 UTC by Folco
Modified: 2019-05-08 06:22 UTC (History)
17 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-01-12 01:52:13 UTC


Attachments (Terms of Use)
log of dnfdragora started from a terminal (4.66 KB, text/plain)
2017-11-07 21:03 UTC, Folco
no flags Details
log of dnfdragora started from a terminal (594 bytes, text/plain)
2017-11-11 16:32 UTC, Folco
no flags Details
Patch that fixes bad closure on exception (1.11 KB, patch)
2018-01-04 18:23 UTC, Angelo Naselli
no flags Details | Diff

Description Folco 2017-11-07 21:03:58 UTC
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.

Comment 1 Angelo Naselli 2017-11-11 11:06:24 UTC
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?

Comment 2 Folco 2017-11-11 11:53:57 UTC
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

Comment 3 Angelo Naselli 2017-11-11 12:19:11 UTC
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

Comment 4 Folco 2017-11-11 16:32 UTC
Created attachment 1350934 [details]
log of dnfdragora started from a terminal

Comment 5 Folco 2017-11-11 16:35:19 UTC
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.

Comment 6 Kevin Kofler 2017-12-03 13:54:12 UTC
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.)

Comment 7 Kevin Kofler 2017-12-03 15:44:38 UTC
The reporter clarified that he meant the dashboard, not the shell called dash.

Comment 8 Krystian 2017-12-17 00:02:29 UTC
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.

Comment 9 Fedora Update System 2017-12-29 23:23:55 UTC
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

Comment 10 Fedora Update System 2017-12-29 23:28:04 UTC
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

Comment 11 Fedora Update System 2017-12-30 19:54:56 UTC
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

Comment 12 Fedora Update System 2017-12-30 20:40:43 UTC
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

Comment 13 Fedora Update System 2017-12-31 21:28:34 UTC
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.

Comment 14 Fedora Update System 2018-01-01 22:12:09 UTC
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.

Comment 15 chris.m.weimer 2018-01-03 17:42:16 UTC
The problem still exists (Fedora 27).

Comment 16 Angelo Naselli 2018-01-03 18:49:09 UTC
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*

Comment 17 chris.m.weimer 2018-01-03 19:49:00 UTC
(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.

Comment 18 Angelo Naselli 2018-01-03 20:37:56 UTC
Maybe you could give me some more information instead, since i cannot replicate it :(

Comment 19 Angelo Naselli 2018-01-04 18:22:02 UTC
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.

Comment 20 Angelo Naselli 2018-01-04 18:23 UTC
Created attachment 1377055 [details]
Patch that fixes bad closure on exception

Comment 21 Kevin Kofler 2018-01-04 19:24:27 UTC
Thanks! Reopening.

Comment 22 Kevin Kofler 2018-01-07 22:52:36 UTC
Ping? Can you please apply this patch and also fix bug #1531118?

Comment 23 Fedora Update System 2018-01-09 10:48:29 UTC
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

Comment 24 Fedora Update System 2018-01-09 10:49:23 UTC
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

Comment 25 Fedora Update System 2018-01-09 17:23:52 UTC
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

Comment 26 Fedora Update System 2018-01-09 17:44:41 UTC
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

Comment 27 Fedora Update System 2018-01-12 01:52:13 UTC
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.

Comment 28 Fedora Update System 2018-01-17 16:00:08 UTC
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.

Comment 29 Ali 2018-04-15 13:38:00 UTC
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.

Comment 30 Ali 2018-04-15 13:52:42 UTC
Thank you.

Comment 31 Marian Adamjak 2018-04-16 21:05:36 UTC
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).

Comment 32 justinacolmena 2018-05-09 22:47:19 UTC
(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.

Comment 33 justinacolmena 2018-05-09 23:07:28 UTC
(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.

Comment 34 Kevin Kofler 2018-05-10 01:37:28 UTC
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!)

Comment 35 John Freed 2018-05-27 09:30:31 UTC
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.

Comment 36 Kevin Kofler 2018-05-27 21:46:09 UTC
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.)

Comment 38 Or Schiro 2018-11-12 09:13:29 UTC
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.

Comment 39 geigor 2018-12-11 09:08:28 UTC
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

Comment 40 Jorge Stolfi 2019-05-08 06:18:48 UTC
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...

Comment 41 Or Schiro 2019-05-08 06:22:57 UTC
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! :)


Note You need to log in before you can comment on or make changes to this bug.