Knowing and managing your background services

Linux system services are one of the most fundamental concepts of every Linux server. They are programs which run continuously in your system, waiting for external events to process something or do it all the time. Normally, when working with your server, a system user will not notice the existence of such a running service because it is running as a background process and is therefore not visible. There are many services running all the time on any Linux server. These can be a web server, database, FTP, SSH or printing, DHCP, or LDAP server to name a few. In this recipe, we will show you how to manage and work with them.

Getting ready

To complete this recipe, you will require a working installation of the CentOS 7 operating system with root privileges, a console-based text editor of your choice, and a connection to the Internet to facilitate the download of additional packages. Some commands shown here use less navigation in their output. Read the Navigating text files with less recipe from Chapter 2, Configuring the System to learn how to browse them.

How to do it...

systemctl is a program that we will use to manage all our background service tasks in a CentOS 7 system. Here, we will show you how to use it, taking the Apache web server service as an example in order to get familiar with it. For a full explanation of Apache, read Chapter 12, Providing Web Services:

1. First, we log in as root and install the Apache web server package:

   yum install httpd
   

2. Next we will check Apache's service status:

   systemctl status httpd.service
   

3. Start the webserver service in the background and print out it's status again:

   systemctl start httpd.service
   systemctl status httpd.service
   

4. Next, let's print out a list of all services currently running in the background of your system; in this list, you should identify the httpd service you just started:

   systemctl -t service -a --state running
   

5. Now, let's make a backup of the Apache configuration file:

   cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.BAK
   

6. Now, we will make some changes to the main Apache configuration file using sed:

   sed -i 's/Options Indexes FollowSymLinks/Options -Indexes +FollowSymLinks/g' /etc/httpd/conf/httpd.conf
   

7. Now, type the following command to stop and start the service and apply our changes:

   systemctl stop httpd.service
   systemctl start httpd.service
   systemctl status httpd.service
   

8. Next, let's enable the httpd service to start automatically at boot time:

   systemctl enable httpd.service
   

9. The last command will show how to restart a service:

   systemctl restart httpd.service
   

How it works...

As we have seen, the systemctl utility can be used to take full control of your system's services. The systemctl is the control program for systemd, which is the system and service manager in CentOS 7 Linux. The systemctl command can be used for a variety of other tasks as well, but here we concentrate on managing services.

So, what have we learned from this experience?

We started this recipe by logging in as root and installed the Apache web server package as we want to use it for showing how to manage services in general using the systemctl program. Apache or the httpd.service, as it is called by systemd, is just an example we will use; other important services that might be running in a basic server environment could be sshd.service, mariadb.service, crond.service, and so on. Afterwards, we checked httpd's current status with the systemctl status command parameter. The output showed us two fields: Loaded and Active. The Loaded field tells us if it is currently loaded and if it will automatically be started at boot time; the Active field denotes whether the service is currently running or not. Next, we showed how to start a service using systemctl. The command's exact starting syntax for services is the systemctl start <name of the service>.service.

Note

By starting a service, the program gets detached from the terminal by forking off a new process that gets moved into the background where it runs as a non-interactive background process. This is sometimes called daemon.

Next, after we started the Apache webserver daemon, we then used systemctl's status parameter again to show how the status changes if we run it. The output shows us that it is currently loaded but disabled on reboot. We also see that it is running, along with the latest logging output from this service and other detailed information about the process. To get an overview of all status information for all services on the system, use systemctl --type service --all. A systemctl service must not be running all the time. Its state can also be stopped, degraded, maintained, and so on. Next, we used the following command to get a list of all currently running services on your system:

systemctl -t service -a --state running

As you can see here, we used the -t flag in order to filter only for type service units. As you may guess, systemctl can not only deal with service units, but also with a lot of other unit types. systemd units are resources systemd can manage using configuration files, and which encapsulate information about services, listening sockets, saved system state snapshots, mounting devices, and other objects that are relevant to the system. To get a list of all possible unit types, type systemctl -t help. These configuration unit files reside in special folders in the system, and the type they belong to can be read from the extension; all the service unit files have the file extension, .service (for example, device unit files have the extension, .device). There are two places where the system stores them. All the systemd unit files installed by the basic system during installation are in /usr/lib/systemd/system, all other services that come from installing packages such as Apache or for your own configurations should go to /etc/systemd/system. We can find our Apache service configuration file exactly at /usr/lib/systemd/system/httpd.service. Next, we showed the user how to stop a service, which is the opposite of starting it, using the syntax, systemctl stop <name of the service>. Finally, as a last step, we used systemctl's restart parameter, which just handles the stopping and starting of a service in one step with less typing. This is often useful if a service hangs and is unresponsive, and you quickly need to reset it to get it working. Before showing how to stop and restart a service, we did another important thing. While the Apache service was running, we changed its main service configuration file with the sed command, adding an -Indexes option that disables the directory web site file listings, and which is a common measure to increase the security of your web server. Since the Apache web server was already running and loading its configuration into memory during service startup, any changes to this file will never be recognized by the running service.

Note

Normally, to apply any configuration file change, running services need a full service restart, because configuration files will normally only be loaded during startup initialization.

Now, imagine that your web server is reachable from the Internet and at the moment there are a lot of people accessing your web pages or applications in parallel. If you restart the Apache normally, the web server will be inaccessible for a while (as long as it takes to restart the server) as the process will actually end and afterwards start all over again. All the current users would get HTML 404 error pages if they were to request something at that moment. Also, all the current session information would have gone; imagine you have an online web shop where people use shopping carts or logging in. All this information would also be gone. To avoid the disruption of important services such as the Apache web server, some of these services have a reload option (but not every service has this feature!) that we can apply instead of the restart parameter. This option just reloads and applies the service's configuration file, while the service itself stays online and does not get interrupted during execution. For Apache, you can use the following command-line: systemctl reload httpd.service. To get a list of all the services that have the reload functionality, use the following lines:

grep -l "ExecReload" /usr/lib/systemd/system/*.service /etc/systemd/system/*.service

So, having completed this recipe, we can say that we now know how to work with the basic systemctl parameters to manage services. It can be a very powerful program and can be used for much more than only starting and stopping services. Also, in this recipe, we have used different names that all mean the same: system service, background process, or daemon.

There's more...

There is another important unit type called target. Targets are also unit files and there are quite a number of them already available in your system. To show them, use the following:

ls -a /usr/lib/systemd/system/*.target /etc/systemd/system/*.target

Simply said, targets are collections of unit files such as services or other targets. They can be used to create runlevel-like environments, which you may know from earlier CentOS versions. Runlevels define which services should be loaded at which system state. For example, there is a graphical state, or a rescue mode state, and so on. To see how the common runlevels correspond to our targets, run the following command, which shows us all the symbolic links between them:

ls -al /lib/systemd/system | grep runlevel

Targets can be dependent on other targets; to get a nice overview of target dependencies, we can run the following command to show all dependencies from the multi-user target to all the other targets (green means active and red means inactive):

systemctl list-dependencies multi-user.target

You can show the current target that we are in at the moment with:

systemctl get-default

You can also switch to another target:

systemctl set-default multi-user.target