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.
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.
systemctl edit Is the Whole Workflow
sudo systemctl edit nginx.serviceThis 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.
[Service]
Environment=NGINX_WORKER_PROCESSES=8
LimitNOFILE=65535
ExecStartPre=/usr/local/bin/check-config.shRegular 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.
[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
systemctl cat nginx.service
sudo systemctl revert nginx.servicesystemctl 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