dnf-plugins-core
dnf-plugins-core copied to clipboard
`generate_completion_cache` does not respect `--setopt=cachedir`
The cache file of the plugin is hard-coded in the code and does not respect --setopt=cachedir:
https://github.com/rpm-software-management/dnf-plugins-core/blob/aee9cacdeb50768c1e869122cd432924ec533213/plugins/generate_completion_cache.py#L34
This causes problems in situations where /var/tmp isn't writable.
Also, there seem some bug in some sqlite3 connected C code called by this plugin, leading a segmentation fault in case the cache dir cannot be created. I didn't find the time to track this down, but here is the error in case you are interested in looking into this:
> Fedora Release 162 MB/s | 34 MB 00:00
> Fedora Updates 162 MB/s | 34 MB 00:00
> Last metadata expiration check: 0:00:08 ago on Thu Nov 16 11:26:11 2023.
> Fatal Python error: Segmentation fault
>
> Current thread 0x00007ffff7ea7740 (most recent call first):
> File "/nix/store/qmslfhyfafm34m6wifipbwnscd1wl2vb-python3.11-dnf-plugins-core-4.4.3/lib/python3.11/site-packages/dnf-plugins/generate_completion_cache.py", line 54 in sack
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/plugin.py", line 107 in _caller
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/plugin.py", line 158 in run_sack
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/base.py", line 437 in fill_sack
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/cli.py", line 741 in _process_demands
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/cli.py", line 1040 in run
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 122 in cli_run
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 106 in _main
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 67 in main
> File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 201 in user_main
> File "/nix/store/m0pla3gf4jx047iyskj96qh4mv04g1li-dnf4-with-plugins/bin/.dnf4-wrapped", line 63 in <module>
Hi, I agree this is an issue when the /var/cache/dnf is not writeable.
Regarding the second part of your report, I was not able to reproduce it running Fedora 38 with current sqlite3 3.40.1. I am getting the expected message in log:
2023-11-20T09:01:33+0100 DEBUG Completion plugin: Can't write completion cache: unable to open database file
What is your configuration please?
What is your configuration please?
The sqlite3 version I observed this with is 3.43.2
I'm on NixOS unstable, running dnf in the Nix sandbox. So /var doesn't exist and can't be created.
Thanks. I recall some reported issues with sqlite3 >= 3.42, will try testing it with some Fedora Rawhide container to reproduce it and figure out the cause. When the bash completion cache is unable to be generated, it should not affect the dnf operation.
Speaking about the hard-coded cache path for packages.db, this could be tricky, given that the path is also used in the bash completion shell script. We are now focusing on the dnf5 successor project, where this is handled differently and should not be an issue. Unless we find an easy fix, addressing this might be beyond our current capacity.
I apologize, but I'm unable to reproduce the issue. I tested the Fedora Rawhide container with dnf 4.18.1, and sqlite 3.44.0 and 3.43.2 versions, but it consistently generates only the log message. I attempted to simulate your scenario by making the /var/cache/dnf directory immutable using the chattr +i command and also by providing a non-existing file path to the sqlite.connect function.
It appears more like a potential bug in the sqlite3 library you're using, as it's not triggering an exception but instead leading to a segmentation fault. I'm not sure what else I can do at this point...
I'll keep the ticket open for the originally reported error with low priority though, as mentioned earlier, our current priorities are different, and this is likely to result in a log report under normal circumstances.
Thanks for investigating this anyway. :) Maybe the bug is in the sqlite3 nix package.