Hide Forgot
Description of problem: stubby-0.3.1-0.5.20200318git7939e965.fc32.x86_64 Version-Release number of selected component (if applicable): stubby-0.3.1-0.5.20200318git7939e965.fc32.x86_64 How reproducible: reliable Steps to Reproduce: 1. dnf install stubby 2. (sudo) systemctl restart stubby 3. Actual results: $ systemctl status stubby ● stubby.service - stubby DNS resolver Loaded: loaded (/usr/lib/systemd/system/stubby.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/stubby.service.d └─custom.conf Active: failed (Result: exit-code) since Fri 2020-10-02 12:19:49 CEST; 39min ago Process: 801782 ExecStart=/usr/bin/stubby -v 5 (code=exited, status=239/CACHE_DIRECTORY) Main PID: 801782 (code=exited, status=239/CACHE_DIRECTORY) CPU: 10ms říj 02 12:19:47 menpad systemd[801782]: Apparently, service previously had DynamicUser= turned off, and has now turned it on. říj 02 12:19:47 menpad systemd[801782]: stubby.service: Failed to set up special execution directory in /var/cache: Permission denied říj 02 12:19:47 menpad systemd[801782]: stubby.service: Failed at step CACHE_DIRECTORY spawning /usr/bin/stubby: Permission denied říj 02 12:19:47 menpad systemd[1]: stubby.service: Main process exited, code=exited, status=239/CACHE_DIRECTORY říj 02 12:19:47 menpad systemd[1]: stubby.service: Failed with result 'exit-code'. říj 02 12:19:49 menpad systemd[1]: stubby.service: Scheduled restart job, restart counter is at 5. říj 02 12:19:49 menpad systemd[1]: Stopped stubby DNS resolver. říj 02 12:19:49 menpad systemd[1]: stubby.service: Start request repeated too quickly. říj 02 12:19:49 menpad systemd[1]: stubby.service: Failed with result 'exit-code'. říj 02 12:19:49 menpad systemd[1]: Failed to start stubby DNS resolver. Expected results: starts and works just fine Additional info: Think it might be about DynamicUser= used. It reports several SELinux failures. type=AVC msg=audit(1601633984.228:70977): avc: denied { rename } for pid=801769 comm="(stubby)" name="stubby" dev="dm-1" ino=2277680 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
It seems there is issue only when /var/cache/stubby is a directory. systemd wants to create symlink from /var/cache/stubby to /var/cache/private/stubby, but it cannot do that. When directory is removed, it can start again. And /var/cache/stubby is not owned by current package, so it remains there also after removal.
FEDORA-2020-22aba50200 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-22aba50200
FEDORA-2020-22aba50200 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-22aba50200` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-22aba50200 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-22aba50200 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.