Don't Touch the Vendor Files
A common mistake is editing unit files directly in /lib/systemd/system/. The problem is straightforward: when you run apt upgrade nginx or yum update nginx, the package manager overwrites that file with the new version, silently discarding your changes. You won't get a warning. Your customization is simply gone.
The correct approach: Drop-In Overrides
Instead of editing the original file, you create a small "drop-in" snippet that contains only the lines you want to change. Systemd merges the drop-in with the original at runtime.
The easiest way to create a drop-in is systemctl edit <unit>, which opens an editor on an empty file for just the overriding directives — for example a new Restart= and RestartSec= value. On save, systemd automatically writes it to /etc/systemd/system/<unit>.service.d/override.conf and runs daemon-reload for you. systemctl cat <unit> then prints the full effective configuration — the original file followed by any drop-ins — with a comment showing which file each section came from. This is invaluable for debugging.
When you need to override a directive that was set in the original file, some directives must be cleared before being reset. For example, to completely replace ExecStart (you can't have two ExecStart lines — the second one appends), the override must first clear it with an empty ExecStart= assignment before providing the new command on the following line. The empty assignment clears the inherited value; the next line sets the new one. This pattern applies to any list-type directive.
Interviewers frequently ask: "How would you customize a systemd service installed by a package without your changes being overwritten on upgrade?" The answer is drop-in override files via systemctl edit, which creates a file in /etc/systemd/system/<name>.service.d/override.conf. Mentioning systemctl cat to verify the merged result demonstrates real operational experience.