Bug 1885101

Summary: systemd %post tries to create /etc/resolv.conf, fails in container
Product: [Fedora] Fedora Reporter: Martin Pitt <mpitt>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: fedoraproject, filbranden, flepied, lnykryn, msekleta, ssahani, s, systemd-maint, yuwatana, zbyszek, z
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-247~rc2-1.fc34 systemd-246.7-2.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-10 01:15:19 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:

Description Martin Pitt 2020-10-05 04:43:50 UTC
Description of problem: systemd %post tries to overwrite an existing and working /etc/resolv.conf in a container with a symlink to resolved's file. "Fortunately" this fails:

  Running scriptlet: systemd-246.6-3.fc34.x86_64                                                                                  25/27 
ln: failed to create symbolic link '/etc/resolv.conf': Device or resource busy
warning: %post(systemd-246.6-3.fc34.x86_64) scriptlet failed, exit status 1

The %post script shouldn't fail, but it helps in this case as actually doing that would break DNS in the container. The script merely checks

   systemctl -q is-enabled systemd-resolved.service

which is true in a podman/docker application container (not full system container with pid 1 == systemd), but it will not actually run.

Instead, I suggest to check if ../run/systemd/resolve/stub-resolv.conf actually exists before linking to it (otherwise it's *definitively* going to break networking).

I'm not sure how reliable this EBUSY is, but let's rather not bet that it will always protect us.

Version-Release number of selected component (if applicable):

systemd-246.6-3.fc34.x86_64

How reproducible: Always


Steps to Reproduce:
1. podman run -it --rm fedora:rawhide dnf install -y systemd

Actual results:

systemd %post fails


Expected results: systemd installs cleanly

Additional info:

Comment 1 Zbigniew Jędrzejewski-Szmek 2020-10-05 06:04:33 UTC
resolved might not be running when the scriplet is executed, so we can't rely on the presence of anything in /run.
But maybe we should check if the file is not a mountpoint too.

Comment 2 Zbigniew Jędrzejewski-Szmek 2020-11-17 15:53:23 UTC
Fixed in rawhide so far.

Comment 3 Fedora Update System 2020-12-08 19:43:49 UTC
FEDORA-2020-3616681a70 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70

Comment 4 Fedora Update System 2020-12-09 02:21:01 UTC
FEDORA-2020-3616681a70 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3616681a70`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2020-12-10 01:15:19 UTC
FEDORA-2020-3616681a70 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.