Systemd: Requires vs wants

Is there any difference between Requires vs Wants in target files?

Description=Graphical Interface 


Asked By: Iewicz


As heemayl noted in the comment, the man page answers your question.
From the web:


A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit.



Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathExists=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).

From the page

Your service will only start if the has been reached (I don’t know what happens if you try to add it to that target?), and systemd will try to start the display-manager.service together with your service.
If display-manager.service fails for whatever reason, your service will still be started (so if you really need the display-manager, use Requires= for that).
If the is not reached however, your service will not be launched.

What is your service? Is it a kiosk system? Intuitively I’d suppose you want to add your service to the (so its launched at startup), and have it strictly depend on the display-manager.service via Requires=display-manager.service. But that’s just wild guessing now.

Answered By: ArchimedesMP

Our server deployment uses LDAP containing all user IDs and automount maps. User home directories are NFS mounted, and the users typically create @reboot cronjobs with the executable code in their home directories. We also use sssd for cache. Needless to say, we have a high reliance on being able to provide a deterministic boot order for this configuration to work. We have developed a very succinct systemd configuration, and have discovered an obscure nuance between the “wants” and “requires” section options.

If you have a failure of a service during boot, and there is another service dependent with “requires” on that service with “restart=always” set as a service option, that dependent service will not restart. If, however, you have “wants” as an option, the dependent service will restart, as expected.

Answered By: billq
Categories: Answers Tags:
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.