Bug 1884575
| Summary: | stubby fails to start | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Menšík <pemensik> |
| Component: | stubby | Assignee: | Petr Menšík <pemensik> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aegorenk, pemensik, pwouters |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | stubby-0.3.1-0.7.20200318git7939e965.fc33 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-23 22:06:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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. |
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