How to write a service unit file which enforces that particular services have to be started

https://access.redhat.com/solutions/3120581

 SOLUTION 已验证 - 已更新 2017年七月20日15:22 - 

English 

环境

• Red Hat Enterprise Linux 7
• systemd

问题

• After=/Before= options don't guarantee the listed units has been started and running. How do I write a service unit file which enforces that particular services have to be started?

决议

Background:

On RHEL7, a service unit file needs to specify its dependencies using After=/Before= options. This ensures that (if configured that way) that, for example, b.service will be started after a.service. What it does not do is ensure that b.service is only started if a.service is successfully started. This is because the After=/Before= options just specify the order of dependencies. Any After=/Before= does not care about if the dependency is running or not.

If a service requires that the dependent services have to be running, you need to consider the options listed below to satisfy that requirement.

Detailed information:

A [Unit] section of a service configuration file can contain following options which enforce a requirement that the listed units must be started and running. The details are quoted from man 5 systemd.unit.

Raw

Requires=
Requisite=
PartOf=

• The details of Requires=
  This option 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.

• The details of Requisite=
  This option is similar to Requires= respectively. However, if the units listed here are not started already, they will not be started and the transaction will fail immediately.

• The details of PartOf=
  This option configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.

How do I choose which option preferred to my unit file?

This section provides some guidance on how to choose the appropriate keyword(s) in your unit file(s). In the following, we assume a.service and b.service have their dependencies as described below.

Raw

a.service (Before=b.service)
b.service (After=a.service)

1. When b.service is activated, a.service should be activated also (if not already). The unit a.service must start successfully - if it fails or is deactivated b.service will also be deactivated.
   You should use Requires= to activate a.service and ensure b.service cannot start unless a.service starts.

2. If a.service is not started already, b.service should not be started and will fail immediately. The activation of a.service should not be triggered by the activation of b.service.
   You should use Requisite= to fulfill the requirement.

3. b.service always needs to be activated after a.service is activated. But a.service should not be activated when b.service is activated however a.service does need to be stopped or restarted when b.service is stopped or restarted.
   You should use PartOf= in this situation.

   You may need to use multiple keywords to achieve a desired outcome. For example, you may have b.service with Requires=a.service so b.service will not start unless a.service starts and starting b.service starts a.service first. As well in the definition of a.service you might need PartOf=b.service so if b.service is stopped or restarted a.service will have the same action taken on it.

   Complex interactions between units can be achieved but requires you to plan out what interactions are required. For other options, please refer to man 5 systemd.unit.