In this guide, we explain how to use systemctl to list services and check on their status. We will also cover some of the other uses for systemctl.
Coming from run_init service, systemctl is a breath of fresh air. I’m sure there are many reasons I’m wrong and I’ve heard the debates for and against it and changed my mind a few times. After using it daily at work, I’m in the systemctl camp now. The language of the command feels more natural now. On a day to day functional level, I like it. I’ve welcomed the change, and resist going back whenever I work on an older system. Let’s go over systemctl and how it works.
Systemctl Status
The first and most important use of systemctl is checking service status. Here’s the syntax:
#systemctl command argument #systemctl status service
There’s your atd service info. Started a while ago (I should reboot…), and active. PID there if I need to kill it, though we can with systemctl too. So what to check? A quick and easy step, check failed services.
#systemctl --failed --type=service
Investigate these and determine if it’s normal. How do you know normal? Check running services:
#systemctl -t service --state=active
After perusing the info, save it.
#systemctl -t service --state=active >date$systemhealth.log
On later days, diff check.
#systemctl -t service --state=active > date$systemhealth.log
#diff day1systemhealth.log day2systemhealth.log
There you go, now you know if something was supposed to be online. If you’re familiarizing yourself with a new system, here’s a good set of services to check.
LAMP
Let’s look at the basic stack most of us learn to deploy in the early days. Oh, and if you don’t know the name of the service you’re looking for. No worry. Tab completion is enabled for systemctl. Simply type in apache, press tab twice, and choose what you need.
#systemctl status apache2.service mongo mysql
Want to get into more detail?
#systemctl list-dependencies apache2.service
It shows all dependencies of the service. And gives you the status of each with a friendly colored dot. Green for good, red for failed.
Network
Next, let’s make sure the network is functional.
#systemctl status networking ufw wpa
If it isn’t clear by now, my favorite feature of systemctl is controlling multiple services simultaneously. And automatically piped into less.
Controlling services
Alright, so now you have some failed services identified. Or you’ve implemented a service change. Like updating your sshd.config file, and need to reload it. Or are you adding a new service, or removing it completely?
It’s simple with systemctl, and you have two options. Reload and restart. Reload simply reads the new config file. Restart drops any connections and reloads the config file. Depending on your need, both have their reasons for use.
Restart and Reload
#systemctl restart atd #systemctl status atd
There we go, restarted. New info added. With robust load balanced systems, I prefer restarting. I know connections will reroute and downtime will be non-existent. At least, almost non-existent. And I won’t have to worry about some systems or services not working nicely with reload. Regardless, always notify users and customers before restarting/reloading.
Stop, Start, and Kill
If you need to halt or kill a service then systemctl can do that too.
#systemctl stop atd #systemctl start atd #systemctl kill atd #systemctl start atd
That’s it, remaking a restart.
Enabling and Disabling
New services that you want to start on boot, need enabling.
#systemctl enable <service>
There we go, your system now understands it needs to start the new service on boot. If you want to skip the reboot, go ahead and start it now.
#systemctl disable <service>
And there we go. Service stopped. If you want to remove it, you’ll need to stop it and then uninstall.
Conclusion
That’s it. Not a lot to it. A single service for a single purpose, controlling your system. Learn more shell commands and how to administer your system.
