packaging-committee

#1467 Clarification on where systemd drop-ins should be packaged
Closed by james. Opened by marcosfrm.

Closed
Reopen Issue

When reporting

https://bugzilla.redhat.com/show_bug.cgi?id=2368862

I noticed that some packages place systemd drop-ins in /etc (possibly marking them as %config). This seems to violate the packaging guidelines, which mandate that systemd unit files be packaged in /usr/lib, likely encompassing drop-in files as well:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging_filesystem

"[...] systemd unit files must put them into %{_unitdir} or %{_userunitdir}. %{_unitdir} evaluates to /usr/lib/systemd/system on all Fedora systems and %{_userunitdir}% evaluates to /usr/lib/systemd/user [...]"

Currently, some packages place drop-ins in /usr/lib:

# dnf repoquery --list | grep '^/usr/lib/systemd/system/.*\.d/'
Updating and loading repositories:
Repositories loaded.
/usr/lib/systemd/system/NetworkManager.service.d/NetworkManager-ovs.conf
/usr/lib/systemd/system/dirsrv@.service.d/custom.conf
/usr/lib/systemd/system/greenboot-healthcheck.service.d/10-network-online.conf
/usr/lib/systemd/system/httpd.socket.d/10-listen443.conf
/usr/lib/systemd/system/keydb-sentinel.service.d/limit.conf
/usr/lib/systemd/system/keydb.service.d/limit.conf
/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
/usr/lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
/usr/lib/systemd/system/nbd@.service.d/modprobe.conf
/usr/lib/systemd/system/redict-sentinel.service.d/limit.conf
/usr/lib/systemd/system/redict.service.d/limit.conf
/usr/lib/systemd/system/service.d/10-timeout-abort.conf
/usr/lib/systemd/system/service.d/50-keep-warm.conf
/usr/lib/systemd/system/sshd-keygen@.service.d/disable-sshd-keygen-if-cloud-init-active.conf
/usr/lib/systemd/system/sshd.service.d/ec2-instance-connect.conf
/usr/lib/systemd/system/system.slice.d/10-oomd-per-slice-defaults.conf
/usr/lib/systemd/system/systemd-firstboot.service.d/override.conf
/usr/lib/systemd/system/systemd-logind.service.d/10-grub2-logind-service.conf
/usr/lib/systemd/system/systemd-logind.service.d/nss_nis.conf
/usr/lib/systemd/system/systemd-udev-trigger.service.d/systemd-udev-trigger-no-reload.conf
/usr/lib/systemd/system/systemd-userdbd.service.d/nss_nis.conf
/usr/lib/systemd/system/unbound.service.d/dnsconfd.conf
/usr/lib/systemd/system/user-.slice.d/10-defaults.conf
/usr/lib/systemd/system/user@.service.d/00-uresourced.conf
/usr/lib/systemd/system/user@.service.d/10-login-barrier.conf
/usr/lib/systemd/system/user@0.service.d/10-login-barrier.conf

While others use /etc:

# dnf repoquery --list | grep '^/etc/systemd/system/.*\.d/'
Updating and loading repositories:
Repositories loaded.
/etc/systemd/system/hitch.service.d/limit.conf
/etc/systemd/system/httpd.d/ipa.conf
/etc/systemd/system/httpd.service.d/php-fpm.conf
/etc/systemd/system/nfs-ganesha-lock.service.d/rpc-statd.conf
/etc/systemd/system/nginx.service.d/php-fpm.conf
/etc/systemd/system/sympa.service.d/dependencies.conf
/etc/systemd/system/sympasoap.socket.d/sympasoap-httpd.conf
/etc/systemd/system/sympasoap.socket.d/sympasoap-nginx.conf
/etc/systemd/system/wwsympa.socket.d/wwsympa-httpd.conf
/etc/systemd/system/wwsympa.socket.d/wwsympa-nginx.conf

(the commands generating these lists were executed on Fedora 42)

In my opinion, placing drop-ins in /etc breaks the contract established by systemd from the beginning, where /usr is the territory of the distribution's package manager, and /etc is the territory of the local administrator. The administrator can, if desired, override the package's drop-ins (in /usr/lib) by creating files with the same name in /etc (to simply disable them, a symbolic link to /dev/null can be used) and running systemctl daemon-reload.

Therefore, I request that the packaging guidelines be updated to explicitly clarify the appropriate location for systemd drop-in files.

The spirit is obviously that nothing packaged for Fedora should go into /etc for systemd ...

@zbyszek Do you have any opinions on what this text should say?

Quick and dirty change would be to have a giant warning there saying "no Fedora packaged systemd config. files should go in /etc" ... but it might be nice to say something specifically about dropins and what macro/etc to use.

I'd suggest the following addition:

Packages with systemd unit files must put them into %{_unitdir} or %{_userunitdir}.

"Unit drop-ins must stored under those paths too (in appropriate subdirectories)."

While at it, I'd reword this part:

Most systemd service files should use %{_unitdir}. However, if the service runs as part of a user session (e.g. pipewire services, gpg-agent, tracker, etc), use %{_userunitdir} instead.

"Files for system services go under %{_unitdir}. Files for user session services (e.g. pipewire services, gpg-agent, tracker, etc.) go under %userunitdir."

("Most" might change over time. We have more and more user unit files. And it doesn't tell the packager anything useful that one location is more commonly used than the other.)

It would be beneficial to update the "%files section" to clarify that not only service unit files but any unit file, including drop-ins, should not be marked as %config.

Gentle ping.

I made an attempt to implement the suggestions from this ticket (plus some other small cleanups and clarifications) here: https://pagure.io/packaging-committee/pull-request/1483

Please take a look.

Metadata Update from @decathorpe:
- Issue tagged with: meeting

Commit 9f5fc87e fixes this issue

Now that the guidelines have been clarified, I plan to open individual Bugzilla tickets for each package to notify the maintainers.

Which target version should I use when filing these bugs? Rawhide?

Please let me know the recommended procedure so I can move forward.

Thanks!

Metadata Update from @marcosfrm:
- Issue close_status updated to: None (was: Fixed)

Yeah, rawhide is generally used for this kind of a thing. It's not a user-visible bug so it's better to not touch released releases.
Metadata
None

meeting

None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.