Description of problem: This crash happens while installing a package, right after "Running transaction" Please note that another dnf-related process is running (but not doing anything) at the same time: dnfdaemon-system from fedora package dnfdaemon. After stopping this daemon (workaround) dnf runs fine. Version-Release number of selected component: dnf-1.1.7-2.fc23 Additional info: reporter: libreport-2.6.4 cmdline: /usr/bin/python3 /usr/bin/dnf install inkscape executable: /usr/bin/dnf kernel: 4.4.5-300.fc23.x86_64 runlevel: N 5 type: Python3 Truncated backtrace: sqlutils.py:167:executeSQLQmark:sqlite3.OperationalError: database is locked 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.4/site-packages/dnf/cli/main.py", line 174, in user_main errcode = main(args) File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 60, in main return _main(base, args) File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 120, in _main ret = resolving(cli, base) File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 149, in resolving base.do_transaction(display=displays) File "/usr/lib/python3.4/site-packages/dnf/cli/cli.py", line 228, in do_transaction super(BaseCli, self).do_transaction(display) File "/usr/lib/python3.4/site-packages/dnf/base.py", line 615, in do_transaction self._run_transaction(cb=cb) File "/usr/lib/python3.4/site-packages/dnf/base.py", line 673, in _run_transaction [], [], cmdline) File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 1004, in beg self._trans_cmdline(cmdline) File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 966, in _trans_cmdline if cur is None or not self._update_db_file_2(): File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 1625, in _update_db_file_2 executeSQL(cur, "PRAGMA table_info(trans_skip_pkgs)") File "/usr/lib/python3.4/site-packages/dnf/yum/sqlutils.py", line 167, in executeSQLQmark return cursor.execute(query) sqlite3.OperationalError: database is locked Local variables in innermost frame: query: 'PRAGMA table_info(trans_skip_pkgs)' params: None cursor: <sqlite3.Cursor object at 0x7ff1f343e6c0> Potential duplicate: bug 1266103
Created attachment 1136296 [details] File: _var_log_dnf.log
Created attachment 1136297 [details] File: backtrace
Created attachment 1136298 [details] File: dnf-makecache.log
We probably need another lock in DNF for sqlite db.
*** Bug 1344850 has been marked as a duplicate of this bug. ***
Also happens when dnf-automatic is running in background while using dnf on CLI.
*** Bug 1350176 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Similar problem has been detected: automatic rebuild (akmod) of VirtualBox kernel module reporter: libreport-2.6.4 cmdline: /usr/bin/python3 /bin/dnf -y install --disablerepo=* /tmp/akmods.8skxMLob/results/kmod-VirtualBox-4.5.5-201.fc23.x86_64-5.0.16-2.fc23.x86_64.rpm event_log: 2016-07-29-21:41:02> (« report_uReport » terminé avec succès) executable: /bin/dnf kernel: 4.4.9-300.fc23.x86_64 package: dnf-1.1.9-2.fc23 reason: sqlutils.py:167:executeSQLQmark:sqlite3.OperationalError: database is locked runlevel: N 5 type: Python3 uid: 0
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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.
I'm getting the same error on Fedora 25 when installing a module via akmod. The same thing has happened twice (with successive updates of the module). This is the latest one from this morning: kmod-nvidia-4.8.15-300.fc25.x86_64 x86_64 2:375.26-1.fc25 @commandline 5.7 M Transaction Summary ================================================================================ Upgrade 1 Package Total size: 5.7 M Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Traceback (most recent call last): File "/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 174, in user_main errcode = main(args) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main return _main(base, args) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in _main ret = resolving(cli, base) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 149, in resolving base.do_transaction(display=displays) File "/usr/lib/python3.5/site-packages/dnf/cli/cli.py", line 228, in do_transaction super(BaseCli, self).do_transaction(display) File "/usr/lib/python3.5/site-packages/dnf/base.py", line 607, in do_transaction self._run_transaction(cb=cb) File "/usr/lib/python3.5/site-packages/dnf/base.py", line 651, in _run_transaction lastdbv = self.history.last() File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 1319, in last ret = self.old([], 1, complete_transactions_only) File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 1268, in old executeSQL(cur, sql, params) File "/usr/lib/python3.5/site-packages/dnf/yum/sqlutils.py", line 167, in executeSQLQmark return cursor.execute(query) sqlite3.OperationalError: database is locked 2016/12/28 09:59:06 akmods: Could not install newly built RPMs. You can find them and the logfile 2016/12/28 09:59:06 akmods: 375.26-1-for-4.8.15-300.fc25.x86_64.failed.log in /var/cache/akmods/nvidia/
(In reply to Patrick O'Callaghan from comment #11) > I'm getting the same error on Fedora 25 when installing a module via akmod. > The same thing has happened twice (with successive updates of the module). > This is the latest one from this morning: > > kmod-nvidia-4.8.15-300.fc25.x86_64 x86_64 2:375.26-1.fc25 @commandline > 5.7 M > > Transaction Summary > ============================================================================= > === > Upgrade 1 Package > > Total size: 5.7 M > Downloading Packages: > Running transaction check > Transaction check succeeded. > Running transaction test > Transaction test succeeded. > Running transaction > Traceback (most recent call last): > File "/bin/dnf", line 58, in <module> > main.user_main(sys.argv[1:], exit_code=True) > File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 174, in > user_main > errcode = main(args) > File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main > return _main(base, args) > File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in _main > ret = resolving(cli, base) > File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 149, in > resolving > base.do_transaction(display=displays) > File "/usr/lib/python3.5/site-packages/dnf/cli/cli.py", line 228, in > do_transaction > super(BaseCli, self).do_transaction(display) > File "/usr/lib/python3.5/site-packages/dnf/base.py", line 607, in > do_transaction > self._run_transaction(cb=cb) > File "/usr/lib/python3.5/site-packages/dnf/base.py", line 651, in > _run_transaction > lastdbv = self.history.last() > File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 1319, in > last > ret = self.old([], 1, complete_transactions_only) > File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 1268, in > old > executeSQL(cur, sql, params) > File "/usr/lib/python3.5/site-packages/dnf/yum/sqlutils.py", line 167, in > executeSQLQmark > return cursor.execute(query) > sqlite3.OperationalError: database is locked > 2016/12/28 09:59:06 akmods: Could not install newly built RPMs. You can find > them and the logfile > 2016/12/28 09:59:06 akmods: 375.26-1-for-4.8.15-300.fc25.x86_64.failed.log > in /var/cache/akmods/nvidia/ Just to add that I'm not running dnfdaemon.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
*** Bug 1515702 has been marked as a duplicate of this bug. ***
*** Bug 1524556 has been marked as a duplicate of this bug. ***
*** Bug 1526690 has been marked as a duplicate of this bug. ***
*** Bug 1538022 has been marked as a duplicate of this bug. ***
*** Bug 1547104 has been marked as a duplicate of this bug. ***
Similar problem has been detected: While dnf-dragora was installing updates, I run sudo dnf history list reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /bin/dnf history list crash_function: executeSQLQmark exception_type: sqlite3.OperationalError executable: /bin/dnf kernel: 4.15.6-300.fc27.x86_64 package: dnf-2.7.5-2.fc27 reason: sqlutils.py:167:executeSQLQmark:sqlite3.OperationalError: database is locked runlevel: N 5 type: Python3 uid: 0
*** Bug 1575955 has been marked as a duplicate of this bug. ***
Same here, but happens consistently on ALL f28 hosts, but none of our f27 hosts. We're running dnf-automatic on all hosts.
(In reply to Trond H. Amundsen from comment #23) > Same here, but happens consistently on ALL f28 hosts, but none of our f27 > hosts. We're running dnf-automatic on all hosts. The reason in my case had nothing to do with dnf. It was a misconfigured localhost SMTP server (in this case postfix). The dnf-automatic process tried to send an email, and when it couldn't it would just hang forever while locking the yum history database. Just a tip for anyone experiencing this issue while using dnf-automatic.. check your localhost MTA :)
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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.
In dnf-4.0.4 (Fedora 29) we have a different implementation how to use historyDB. Therefore I believe that the problem is gone.
(In reply to Jaroslav Mracek from comment #26) > In dnf-4.0.4 (Fedora 29) we have a different implementation how to use > historyDB. Therefore I believe that the problem is gone. In my case the problem only appeared with F29. I had never seen it before upgrading and I've been using tracer for years. Therefore it is not the case that it has been fixed.