Bug 1844465

Summary: [spec] dbus-org.freedesktop.resolve1.service file is listed as a configuration file in systemd package
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Frantisek Sumsal <fsumsal>
Severity: low Docs Contact:
Priority: low    
Version: 8.2CC: dtardon, fweimer, mezhang, peter.vreman, systemd-maint-list, trevor.hemsley, yuxisun
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-04 02:02:49 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:

Description Renaud Métrich 2020-06-05 13:34:27 UTC
Description of problem:

A customer reported that after disabling systemd-resolved (which installs dbus-org.freedesktop.resolve1.service in /etc/systemd/system), the /etc/systemd/system/dbus-org.freedesktop.resolve1.service was showing as missing in "rpm -V systemd" output.

Digging further, it appears that the root cause is /etc/systemd/system/dbus-org.freedesktop.resolve1.service is installed in the build root, hence gets included in the systemd package when split-files.py collects the files in the build root.

split-files.py (see line 107 and 108):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
103     if n in known_files:
104         prefix = ' '.join(known_files[n].split()[:-1])
105         if prefix:
106             prefix += ' '
107     elif file.is_dir() and not file.is_symlink():
108         prefix = '%dir '
109     elif n.startswith('/etc'):
110         prefix = '%config(noreplace) '
111     else:
112         prefix = ''
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

I believe the file should be excluded, as a systemd preset should then enable the service upon systemd installation.

However there is a 2nd issue: apparently "systemctl preset systemd-resolved" doesn't work even though "systemd-resolved" is listed in systemd presets:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# grep systemd-resolved /usr/lib/systemd/system-preset/*
/usr/lib/systemd/system-preset/90-default.preset:disable systemd-resolved.service
/usr/lib/systemd/system-preset/90-systemd.preset:enable systemd-resolved.service
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Nothing happens when executing "systemctl preset systemd-resolved".


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

systemd-239


How reproducible:

Always


Steps to Reproduce:
1. Disable systemd-resolved

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  # systemctl disable systemd-resolved
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

2. Check RPM

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  # rpm -V systemd
  [...]
  missing   c /etc/systemd/system/dbus-org.freedesktop.resolve1.service
  [...]
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

3. Try to enable systemd-resolved using the preset

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  # systemctl preset systemd-resolved
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Actual results:

systemd-resolved is not enabled

Comment 1 David Tardon 2020-06-08 07:30:09 UTC
(In reply to Renaud Métrich from comment #0)
> # grep systemd-resolved /usr/lib/systemd/system-preset/*
> /usr/lib/systemd/system-preset/90-default.preset:disable
> systemd-resolved.service
> /usr/lib/systemd/system-preset/90-systemd.preset:enable
> systemd-resolved.service
> 
> Nothing happens when executing "systemctl preset systemd-resolved".

This works as expected. From systemd.preset(5): "If multiple lines apply to a unit name, the first matching one takes precedence over all others." So the global setting in 90-default.preset (from redhat-release-server package) overrides the systemd setting in 90-systemd.preset.

Comment 2 Renaud Métrich 2020-06-08 07:39:42 UTC
So this means that systemd-resolved should be disabled at boot, which isn't the case since "dbus-org.freedesktop.resolve1.service" is installed in /etc/systemd/system, so "partially" enabled (if a service does a DBus request, it will start).

Comment 3 David Tardon 2020-06-08 07:54:28 UTC
(In reply to Renaud Métrich from comment #2)
> So this means that systemd-resolved should be disabled at boot, which isn't
> the case since "dbus-org.freedesktop.resolve1.service" is installed in
> /etc/systemd/system, so "partially" enabled (if a service does a DBus
> request, it will start).

Yes. That gets us back to the real bug: the symlink shouldn't be packaged.

Comment 11 David Tardon 2020-08-25 09:26:36 UTC
*** Bug 1871934 has been marked as a duplicate of this bug. ***

Comment 15 errata-xmlrpc 2020-11-04 02:02:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: systemd security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4553

Comment 16 David Tardon 2021-06-16 11:08:36 UTC
*** Bug 1972489 has been marked as a duplicate of this bug. ***