Systemctl: How to List Services (Status, Control, and Tips)

Systemctl: Status, Control, and Tips

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
systemctl status service

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
systemctl --failed --type=service

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
systemctl -t service --state=active

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
diff day1systemhealth.log day2systemhealth.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.


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 apache

systemctl status apache

#systemctl status apache2.service mongo mysql
systemctl status apache2.service mongo mysql

systemctl status apache2.service mongo mysql

Want to get into more detail?

#systemctl list-dependencies apache2.service
systemctl list-dependencies apache2.service

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.


Next, let’s make sure the network is functional.

#systemctl status networking ufw wpa
systemctl status networking ufw wpa

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
systemctl restart atd

systemctl restart 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.

systemctl status atd

systemctl status atd

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.


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.


Samuel Berry

I'm a writer, in the sense that there are words written and things needing explaining. Years of schooling, running on twelve now, taught me one thing, I like taking the complicated down to complex. So, I'm writing about Linux. One of those things that starts as complicated, and after a few years turns into complex. Until the next new thing rolls out anyways. Working in IT, I learned advocating for your product is the only way to ensure adoption. Providing user manuals, pictures, diagrams, and everything else possible to our community. That's what builds the "user-friendly" experience. Not only design, but inclusion. Talk to me about Linux, I'm here to learn by teaching.

Leave a Reply

Your email address will not be published. Required fields are marked *