Lab 7 - Services
Facilitator: Ryan Ma6 min read
- Using systemd
On your provided virtual machine, run
systemctl. You’ll see a long table of every unit known to systemd.
Let’s narrow it down to services for now. Run
systemctl --type=service. Now you can see a list of all services running on your virtual machine. Each of these services is a daemon running in the background. Do you see any familiar services running?
Now let’s use
systemd to control a an nginx web server. Again on your virtual machine, install nginx by issuing
sudo apt install nginx. Once that is done, we can tell systemd to start the service with the following:
sudo systemctl start nginx. Run
systemctl status nginx to ensure it is running and navigate to http://yourvm.decal.xcf.sh/ – you should be greeted by the nginx default landing page.
Now let’s make nginx listen for connections on the nonstandard port 420. Using a terminal text editor, change the following lines in
listen 80 default_server; listen [::]:80 default_server;
listen 420 default_server; listen [::]:420 default_server;
Tell systemd that nginx has changed configuration and needs reloading with:
sudo systemctl reload nginx. Now, accessing http://yourvm.decal.xcf.sh/ should now give you a connection refused error and your webserver will only be accessible via http://yourvm.decal.xcf.sh:420/.
Note that not all services can be reloaded; systemd will notify you if this is the case and such services will have to be restarted instead with:
sudo systemctl restart yourservice.
Finally go ahead and stop the nginx service with
sudo systemctl stop nginx.
Exercise 1: What is the difference between
systemctl reload yourservice and
systemctl restart yourservice?
Exercise 2: Which file determines what exactly happens when
systemctl reload yourservice is called on different services?
Let’s set up a web server and create a systemd unit for it. Make sure
git is installed; if it’s not, install it using apt.
To get the code run:
git clone https://github.com/0xcf/decal-labs.git
If you have already cloned the repository, go to your
decal-labs directory and run
git pull. The materials for this part of the lab will be in the
We will also need to install some dependencies. Go ahead and execute the following commands:
sudo apt update sudo apt install build-essential make python3-virtualenv
./run. This should start up a simple web server at
If you’re having issues reaching the site on your browser, try accessing it from a shell using a command like
Your mission, should you choose to accept it, is to write a systemd service that manages this web server. To do this, make a new unit file in
sudo to give yourself privileges if necessary). Refer to the slides for an example; DigitalOcean also has a good guide on how to write systemd units. Here is a skeleton; all you need to do is fill in the values for each field.
[Unit] Description= Requires= After= [Install] WantedBy=multi-user.target [Service] ExecStart= User=
Some questions worth considering while writing this unit file are:
- What units needs to be started before a webserver starts (Hint: network)?
- What script should systemd run to start the webserver?
- Units run by root as default. Is that a safe practice for web servers?
You are encouraged to experiment with other fields as suits your liking.
- Hint: If you’re stuck, try taking a look at the unit file for nginx.
- Hint: If you can’t find the service file, know that a certain command used to display service information for a given service will also display the unit file path
Once you have finished creating
toy.service, let’s start the service and have the it start whenever our machine is booted.
sudo systemctl start toy.service sudo systemctl enable toy.service
You can check if the unit file succeeded by running
systemctl status toy.service. If you are having issues with the unit file or the web server, check the logs for this unit by running
journalctl -u toy.service. If you run into errors don’t get demoralized (it is, after all, only a decal); as a sysadmin you’ll have to become comfortable making sense of arcane error messages.
One of the great benefits of using systemd to manage your services is that you don’t have to worry unnecessarily about bringing a process back up if it crashes. So let’s crash the service! You can do this by either sending a POST request with the json payload
http://yourvm.decal.xcf.sh:5000/crash (Hint: use
curl with the
--data option) or by killing the webserver manually by sending a signal (using
kill) – both will cause the unit to crash. You can verify if you succeeded by running
systemctl status toy.service, and the unit should either be in an
failed state, depending on how you killed it.
Now add the following the
/etc/systemd/system/toy.service under the
To tell systemd that the unit file has changed run
sudo systemctl daemon-reload. Now start your webserver and kill it again in any way you please, and you should see that it come back online after 10 seconds! Note that you can also run daemon-reload and change a unit file while a service is running.
Exercise 3: Submit your
Congratulations, you have completed the lab! This is just the tip of the iceberg when it comes to processes and services. If you want to learn more, here are some related topics you can look into.
- Wikipedia’s article on init systems
- The construction of a basic init system
- Yelp’s dumb-init, a lightweight init system for docker containers
- Zombie Processes
- Socket activation
- Systemd has been the source of a considerable amount of controversy. Opponents allege that it violates the Unix philosophy of “do one thing and do it well”, and that it has had too much scope creep, among other complaints.
- Everything you wanted to know about Unix threads, processes, process groups and sessions. Bear in mind that this document is a little dated when it comes to the code about threads, and its description of what happens when a pseudotty is closed is not actually correct.