The WantedBy value in the system definition file isn&#x27;t an absolute (nor are the similar values Wants&#x2F;Requres&#x2F;RequiredBy&#x2F;etc). Instead they are defaults.<p>What systemd actually does at startup, or when starting services individually, is look for symlinks. If I have a foo.service and a bar.service, and a symlink called foo.service.d&#x2F;bar.service -&gt; ..&#x2F;bar.service, then systemd will start bar.service automatically whenever I ask it to start foo.service. If it also sees a multi-user.wants.d&#x2F;foo.service -&gt; ..&#x2F;foo.service, then it will start foo (and also bar) whenever it enters the multi-user &quot;runlevel&quot;. (This is almost exactly how sysv runlevels work, except that they&#x27;re named rather than numbered, and they can depend on each other.)<p>I can make that symlink manually, if I want, or I can call &quot;systemctl enable foo.service&quot; in which case systemd will read the dependency information from the .service files and make the appropriate symlinks.<p>If I don&#x27;t like how the distro or packager has set up the service file, I can override it. The service files live in &#x2F;etc&#x2F;systemd&#x2F;system by default, but systemd also looks in &#x2F;var&#x2F;systemd&#x2F;system for overrides. This is the real reason why systemd uses key=value stores for units; merging them is trivial while merging shell scripts is decidedly not.<p>Putting the overrides in a separate directory is a pretty nice decision; it&#x27;s always obvious what changes have been made, and upgrades never overwrite them. I can even put those overrides into version control and track changes to them over time.