GemFire: Systemd Service Fails to Start Due to Circular Dependency

Products

• VMware Tanzu Gemfire
• VMware Tanzu Data Intelligence
• VMware Tanzu Data Suite
• VMware Tanzu Data Suite

Issue/Introduction

A service may fail to start during boot when systemd detects an ordering cycle between units. In this situation, systemd may drop one or more jobs from the transaction to break the loop, which can prevent the service from starting successfully.

Cause

The root cause is usually an invalid or unnecessary dependency relationship in one or more unit files. Common examples include:

• A service using After= or Requires= against a target that is already part of the boot transaction in a way that creates a loop.
• A service being ordered against default.target instead of a more appropriate boot target such as multi-user.target.
• Restart-related settings being misapplied, such as defining RestartSec= while Restart= is disabled.

When systemd detects an unresolvable cycle, it breaks the transaction by removing a job, which can leave the service inactive.

Resolution

Review the service unit files and remove dependency relationships that create circular ordering. In most cases:

• Use multi-user.target for normal boot-time service startup.
• Avoid After=default.target unless there is a specific reason for it.
• Ensure restart settings are consistent, for example RestartSec= only has an effect when Restart= is enabled.
• Verify that service ordering is based on the actual prerequisite unit, not the default boot target.

Example Unit

[Unit]
Description=Example Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/example-service
Restart=on-failure
RestartSec=60

[Install]
WantedBy=multi-user.target

In this example, the service is started as part of the normal multi-user boot process and avoids unnecessary dependency on default.target.