In this lesson, you will learn how to orchestrate complex service dependencies so your startup sequence remains resilient even when components start at different speeds.
When building a multi-service stack—such as a database, a message broker, and an application server—simple "start order" isn't enough. If your application attempts to connect to a database that is still initializing its storage engine, the application will crash. To build a resilient startup, you must move beyond basic ordering and implement strict readiness checks.
Defining Order vs. Readiness
While After= defines the desired startup sequence, it only tells systemd when to begin starting a unit; it doesn't guarantee the previous service is actually functional. To bridge this gap, we use two specific directives in our application unit file:
Requires=: Creates a hard dependency. If the database fails to start, your application will stop trying.After=: Ensures the database service is triggered before the application.
However, to truly handle the "lag" between a service starting and being ready to accept connections, we combine these with Type=notify or Type=exec combined with a PIDFile. For modern applications, Type=notify is the gold standard: the application sends a signal to systemd via sd_notify() once it is fully initialized.
Example Orchestration
Consider an application that requires a database. Your app.service should look like this:
[Unit]
Description=My Resilient Application
Requires=database.service
After=database.service
[Service]
Type=notify
ExecStart=/usr/bin/my-app
Restart=on-failure
RestartSec=5s
By setting Restart=on-failure, systemd handles the inherent volatility of a startup sequence. If the application crashes because the database wasn't quite ready despite the After= directive, systemd will automatically retry the launch after five seconds, effectively "waiting" for the stack to stabilize without human intervention.
This approach shifts the burden of resilience from brittle shell scripts to the system manager itself, ensuring that your stack recovers gracefully from transient startup errors.
Key Takeaway: Build resilience by combining explicit ordering (After=) with automatic recovery (Restart=on-failure) and explicit readiness signaling (Type=notify).