Drop-in overrides — modifying units without rewriting

Drop-ins are the production-grade way to make partial overrides to vendor-provided units. They preserve the upstream file, make the diff explicit, and survive package updates.

The drop-in directory

For any unit <name>.service, the drop-in directory is /etc/systemd/system/<name>.service.d/. Files in this directory are merged into the unit on top of the vendor file.

/usr/lib/systemd/system/
└── sshd.service                            # VENDOR unit, shipped by the package.
                                            # Do not edit: the next package
                                            # upgrade overwrites it.

/etc/systemd/system/
├── sshd.service.d/
│   └── override.conf                       # our drop-in: merged on top of the vendor unit
├── sshd.service                            # a FULL replacement, if one exists here.
│                                           # Shadows the vendor unit entirely and
│                                           # silently ignores the drop-in above.
└── myapp.service                           # our own unit, no vendor file to merge with

Three directories, in increasing order of precedence: /usr/lib/systemd/system/ (the package’s), /run/systemd/system/ (generated at runtime), /etc/systemd/system/ (yours). Everything under /etc is the administrator’s to edit — that is the whole point of the directory. What must not be edited is the vendor file under /usr/lib, because the package owns it.

Note the trap in the tree above. A full unit file at /etc/systemd/system/sshd.service replaces the vendor unit outright, and once it exists the sshd.service.d/ drop-in applies to your copy rather than to the vendor’s. Teams end up with both, edit the drop-in, and see no change. systemctl cat sshd shows which files are actually in play, in order:

systemctl cat sshd | head -1     # the path of the unit actually loaded
systemd-delta --type=overridden  # every vendor unit shadowed by an /etc copy

$ ls -l /etc/systemd/system/sshd.service.d/

-rw-r--r-- 1 root root 230 Aug  9 11:11 10-override.conf
-rw-r--r-- 1 root root 120 Aug  9 11:11 20-logging.conf

Using systemctl edit

$ sudo systemctl edit sshd.service

The file produced by systemctl edit looks like:

### Editing /etc/systemd/system/sshd.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStart=
ExecStart=/usr/sbin/sshd -D -e

### Lines below this comment will be discarded

The ExecStart= (empty) line clears the inherited directive. The ExecStart=/usr/sbin/sshd -D -e line sets the new value. The comment at the bottom is the safety net — anything below it is discarded on save.

Adding directives without clearing

$ sudo systemctl edit sshd.service

[Service]
MemoryMax=2G

Multiple drop-ins

A unit can have multiple drop-in files. Each one is merged on top of the vendor file in lexical order. The convention:

• 10-*.conf for host-wide overrides (one per concern).
• 20-*.conf for environment-specific overrides.
• 99-override.conf for the last-resort override.

Use multiple drop-ins when multiple teams or automation tools need to make changes that should not collide. Configuration management (Ansible, Puppet) typically uses one drop-in per service.

Revert or modify

$ sudo systemctl revert sshd.service

Removed /etc/systemd/system/sshd.service.d/override.conf.

Verifying the merged unit

$ systemctl cat sshd.service

# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenBSD Secure Shell server
...

# /etc/systemd/system/sshd.service.d/override.conf
[Service]
MemoryMax=2G
...

Knowledge check