Systemd dependencies example

January 31, 2017


We use systemd unit quite a bit. Getting dependencies correct can be tricky. We use systemd to start up Cloudurable Cassandra config scripts. We use systemd to start up Cassandra/Kafka, and to shut Cassandra/Kafka down nicely.

Since systemd is pervasive in all new mainstream Linux distributions, you can see that systemd is an important concept for DevOps.

We wrote this little example to try to understand how systemd dependencies work, and explain it to others.

Let’s say that you have two services as follows:

Service A

$ cat /etc/systemd/system/a.service
Description=Service A



A is a service that runs to start up and to stop.

Cloudurable specialize in AWS DevOps Automation for Cassandra and Kafka

We hope this brief article on systemd setup useful. We use systemd to write services that monitor Cassandra, Kafka and the OS. These systemd services do log aggregation to AWS CloudWatch and are written in Go Lang. These systemd services also monitor Cassandra and Kafka, report metrics and trigger Alarms in AWS CloudWatch. Support us by checking out our Casandra training and Kafka training. We also provide Casandra consulting and Kafka consulting to get you setup fast in AWS with CloudFormation and CloudWatch.

Service B

$ cat /etc/systemd/system/b.service
Description=Service B



Notice we use After to force ordering. Service B Requires Service A. If you start B then A will start as well. Also on reboot. Service B will shutdown first and Service A will shutdown second. A will start before B. B will shutdown before A.

Sample session

[root@localhost vagrant]# systemctl start b
[root@localhost vagrant]# reboot

Connection to closed by remote host.
Connection to closed.

# Log back in
$ vagrant ssh node0
Last login: Wed Feb  1 01:33:46 2017 from

# Show that B gets stopped before A
[vagrant@localhost ~]$ cat /opt/b/stop.txt
B STOPPED Wed Feb  1 01:37:18 UTC 2017
[vagrant@localhost ~]$ cat /opt/a/stop.txt
A STOPPED Wed Feb  1 01:37:20 UTC 2017

# Show that A gets started before B
[vagrant@localhost ~]$ cat /opt/a/start.txt
A STARTED Tue Jan 31 16:09:16 UTC 2017
[vagrant@localhost ~]$ cat /opt/b/start.txt
B STARTED Tue Jan 31 16:09:18 UTC 2017

Notice that we start up Service B, which requires that A is started before B. Systemd sees that A is not running and runs Service A on behalf of B.

The scripts to run service A and service B are quite simple. for A and B service

[vagrant@localhost ~]$ cat /opt/a/bin/
sleep 1
export TS=`date`
echo "A STARTED $TS" >> /opt/a/start.txt
sleep 1

[vagrant@localhost ~]$ cat /opt/a/bin/
sleep 1
export TS=`date`
echo "A STOPPED $TS" >> /opt/a/stop.txt
sleep 1

[vagrant@localhost ~]$ cat /opt/b/bin/
sleep 1
export TS=`date`
echo "B STARTED $TS" >> /opt/b/start.txt
sleep 1

[vagrant@localhost ~]$ cat /opt/b/bin/
sleep 1
export TS=`date`
echo "B STOPPED $TS" >> /opt/b/stop.txt
sleep 1

About us

Cloudurable™ streamline DevOps for Cassandra running on AWS provides AMIs, CloudWatch Monitoring, CloudFormation templates and monitoring tools to support Cassandra in production running in EC2. We also teach advanced Cassandra courses which teaches how one could develop, support and deploy Cassandra to production in AWS EC2 for Developers and DevOps.

More info

Please take some time to read the Advantage of using Cloudurable™.

Cloudurable provides:

Check out our new GoLang course. We provide onsite Go Lang training which is instructor led.


Kafka Tutorial
Akka Consulting
Cassandra Training
AWS Cassandra Database Support
Kafka Support Pricing
Cassandra Database Support Pricing
Non-stop Cassandra
Advantages of using Cloudurable™
Cassandra Consulting
Cloudurable™| Guide to AWS Cassandra Deploy
Cloudurable™| AWS Cassandra Guidelines and Notes
Free guide to deploying Cassandra on AWS
Kafka Training
Kafka Consulting
DynamoDB Training
DynamoDB Consulting
Kinesis Training
Kinesis Consulting
Kafka Tutorial PDF
Redis Consulting
Redis Training
ElasticSearch / ELK Consulting
ElasticSearch Training
InfluxDB/TICK Training TICK Consulting