As far as I can tell from the documentation of systemd, Wants= and WantedBy= perform the same function, except that the former is put in the dependent unit file and vice-versa. (That, and WantedBy= creates the unit.type.wants directory and populates it with symlinks.)

From DigitalOcean: Understanding Systemd Units and Unit Files:

The WantedBy= directive... allows you to specify a dependency relationship in a similar way to the Wants= directive does in the [Unit] section. The difference is that this directive is included in the ancillary unit allowing the primary unit listed to remain relatively clean.

Is it really just about keeping a unit file "clean"? What is the best practice for using these two directives? That is, if service alpha "wants" service beta, when should I use Wants=beta.service in alpha.service and when should I prefer WantedBy=alpha.service in the beta.service?

2 Answers 2



Wants is in the Unit section and WantedBy is in the Install.

The init process systemd does not process/use the Install section at all. Instead, a symlink must be created in multi-user.target.wants. Usually, that's done by the utility systemctl which does read the Install section.

In summary, WantedBy is affected by systemctl enable/systemctl disable.


Consider which of the services should "know" or be "aware" of the other. For example, a common use of WantedBy:


Alternatively, that could be in multi-user.target:


But that second way doesn't make sense. Logically, nginx.service knows about the system-defined multi-user.target, not the other way around.

So in your example, if alpha's author is aware of beta, then alpha Wants beta. If beta's author is aware of alpha then beta is WantedBy alpha.

To help you decide, you may consider which service can be installed (say, from a package manager) without the other being present.

Config directories

As another tool in your box, know that systemd files can also be extended with config directories: /etc/systemd/system/myservice.service.d/extension.conf

This allows you to add dependencies where neither service is originally authored to know about the other. I often use this with mounts, where (for example) neither nginx nor the mount need explicit knowledge of the other, but I as the system adminstrator understand the dependency. So I create nginx.service.d/mymount.conf with Wants=mnt-my.mount.

  • 1
    Super helpful. I have an issue where nginx is failing on boot because the vpn interface it binds to hasn't started yet. Based on the last section, it sounds like Wants is best fix for this init race condition.
    – ki9
    Sep 7, 2020 at 3:17
  • Also, if WantedBy is more useful for runtime with systemctl, will it try to start the dependent service automatically when you systemctl start alpha?
    – ki9
    Sep 7, 2020 at 3:18
  • 2
    @Keith, yes WantedBy will start prerequisite service first. It will not however, prevent the other service from starting should the prerequisite fail. (For a stronger dependency, see RequiredBy.) Sep 7, 2020 at 16:32

These are not functionally identical. The Wants= setting (and the symbolic link files) is the dependency. The WantedBy= setting controls the creation/destruction of such a dependency when a service is enabled/disabled.

So there's no best practice. There's correct practice. Only one of the two has the correct functionality for any given situation. Either one intends to have a persistent dependency that always exists, or one intends to have a transient dependency that can be turned on and off with enable/disable.

  • 2
    Thanks, but I still don't understand. Could you give examples of when each would be correct?
    – ki9
    Apr 11, 2020 at 23:17
  • 2
    I second Keith's question: the answer does not really help understand the distinction and examples would make a big difference.
    – user339730
    Apr 19, 2020 at 2:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .