Linux Administration·6 min read·

override.conf: Customizing Vendor Units Without Losing Updates

Use systemctl edit and drop-in override.conf files to customize vendor units safely, so package upgrades never clobber your production changes.

NB

Netbay Engineering

Netbay Engineering

On this page

Sooner or later you need to change a unit file that ships with your distribution or a package: raise a file-descriptor limit, add an environment variable, make a service start a few seconds later. If you edit the vendor file in /usr/lib/systemd/system, the next package upgrade silently reverts your work. systemd has a purpose-built answer: drop-in overrides, managed by one command.

Where systemd Looks, In Order

For any unit, systemd searches a fixed path order and merges what it finds: /etc/systemd/system wins over /run/systemd/system, which wins over /usr/lib/systemd/system. Package files live in /usr/lib, runtime overrides in /run, and administrator files in /etc — the system is designed around the rule that your changes live in /etc and packages never touch it.

Drop-ins extend the same idea: for a unit named nginx.service, every file ending in .conf inside /etc/systemd/system/nginx.service.d/ is applied on top of the base file, in lexical order.

Nothing forces you to name the file override.conf, by the way. Any name ending in .conf works, and once you have more than one, explicit numeric prefixes keep the application order predictable: 10-limits.conf, 20-networking.conf. Many admins keep one drop-in per concern instead of one ever-growing file, which makes review and selective reverts trivial.

Unit file resolution: /etc wins, drop-ins stack on top /etc/systemd/system nginx.service.d/override.conf /run/systemd/system runtime, volatile /usr/lib/systemd/system vendor files from packages wins over wins over effective unit systemctl cat shows the merged view

systemctl edit Is the Whole Workflow

bash
sudo systemctl edit nginx.service

This opens an editor on a brand-new file at /etc/systemd/system/nginx.service.d/override.conf, creating the directory if needed. When you save and exit, systemd rewrites the drop-in and runs daemon-reload for you. One command, correct path, correct reload. It also accepts --full when you truly want a complete editable copy of the unit placed in /etc, but start with the drop-in.

What Goes in the Drop-In

A drop-in contains only the sections and keys you are changing; everything else inherits from the base unit untouched.

ini
[Service]
Environment=NGINX_WORKER_PROCESSES=8
LimitNOFILE=65535
ExecStartPre=/usr/local/bin/check-config.sh

Regular keys such as Environment= or LimitNOFILE= simply override their base values. ExecStart= is the famous exception: list-based directives must be cleared before they are set, or systemd appends a second ExecStart and the unit fails to load with an error about duplicate entries.

ini
[Service]
ExecStart=
ExecStart=/usr/sbin/nginx -g "worker_processes 8;"

That first empty ExecStart= is not a typo. It resets the value inherited from the vendor file, and the second line sets the new one. Forget it and you will meet the error message eventually; everyone does.

Drop-ins are not limited to [Service], either. A [Unit] section in a drop-in can override Description= to rename the unit in status output, and After= or Wants= entries there merge with the base dependencies rather than replacing them. The underlying rule is simple: scalar keys replace, list-based keys append. Knowing which kind a key is resolves most override confusion in advance.

Inspecting and Reverting

bash
systemctl cat nginx.service
sudo systemctl revert nginx.service

systemctl cat prints the effective unit: the vendor file with every drop-in shown underneath, in the order it is applied. It is the fastest way to answer why a service behaves this way on a machine other people have administered. The same question works the other direction: systemctl show nginx -p LimitNOFILE prints the value systemd will actually enforce after every drop-in is merged, which settles any argument about what is in effect. systemctl revert then deletes your /etc drop-ins and copies, returning the unit to pure vendor defaults — a clean undo button.

One more tool for completeness: systemctl mask unit.service creates a symlink to /dev/null in /etc that makes the unit impossible to start at all, even when something else tries to pull it in. That is the strongest available way to keep a distro service from ever running.

Takeaway: never edit /usr/lib. systemctl edit for surgical changes, systemctl cat to see the merged truth, systemctl revert to undo. Package upgrades stop being a threat to your configuration.

Tune units on a real server instead of a VM on your laptop — Netbay instances boot in under 60 seconds at netbayhosts.in.

Keep reading

Follow along on a real VPS

Deploy Linux in under 60 seconds

These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.

Deploy an instance