Chapter 9: Control Services and Daemons

Welcome back to my blog series on RH124! In today's chapter 9, we will delve into the world of system daemons and network services, and learn how to effectively control and manage them using the powerful systemd service in Linux. Systemd has become the standard initialization system in many Linux distributions, including Red Hat Enterprise Linux (RHEL), and provides a comprehensive suite of tools for managing services and daemons. Understanding how to work with systemd is essential for any Linux system administrator, as it allows for efficient control and monitoring of various services that are critical for the smooth operation of a Linux system. In this chapter's lab, we will get hands-on experience configuring services to be enabled or disabled, running or stopped, based on given specifications. We will learn how to list system daemons and network services that are started by systemd service and socket units, and how to control them using the systemctl command. This will enable us to have fine-grained control over the services running on our Linux system, ensuring efficient resource utilization and smooth performance. So let's dive in and master the art of controlling services and daemons with systemd, as we explore the powerful features it offers in managing the services that keep our Linux systems humming along smoothly. Let's get started with the lab tasks and unlock the full potential of systemd in our system administration journey!

Question 1: Use the ssh command to log in to the serverb machine as the student user. On the serverb machine, start the psacct service.

Solution:

As the student user, I logged in to the serverb machine using the ssh command. After switching to the root user with sudo -i, I checked the status of the **psacct** service using systemctl status psacct. The service was found to be inactive. To start the psacct service, I ran the command systemctl start psacct. To confirm that the service is now active, I used the command systemctl is-active psacct, which returned "active" as the output. The psacct service is now successfully started and ready for use.

Question 2: Configure the psacct service to start at system boot.

Solution:

To ensure that the psacct service starts automatically at system boot, I used the systemctl enable psacct command. This configures the service to be enabled during the boot process. To confirm that the psacct service is now enabled, I used the systemctl is-enabled psacct command, which returned "enabled" as the output. This confirms that the psacct service is now configured to start automatically at system boot, ensuring that it will be available for use even after a system reboot.

Question 3: Stop the rsyslog service.

Solution:

To stop the rsyslog service, I first checked its status using the **systemctl** status rsyslog command. This confirmed that the service was currently running. Next, I used the systemctl stop rsyslog command to stop the service. To confirm that the service was stopped, I used the systemctl is-active rsyslog command, which returned "inactive" as the output. The rsyslog service has been successfully stopped and is no longer running on the system.

Question 4: Configure the rsyslog service so that it does not start at system boot.

Solution:

To prevent the rsyslog service from starting automatically at system boot, I used the systemctl disable rsyslog command. This disables the service from being enabled during the boot process. To confirm that the rsyslog service is now disabled, I used the systemctl is-enabled rsyslog command, which returned "disabled" as the output. This confirms that the rsyslog service will not start automatically at system boot, as per the configuration made with the systemctl disable command.

Question 5: Reboot the serverb machine before evaluating the lab.

Solution:

To complete the lab, I used the systemctl reboot command to reboot the serverb machine. This command initiates a system reboot, allowing any changes made to take effect. After executing the command, my connection to serverb was closed, and I returned to the workstation. The system reboot ensures that any changes made to the services and daemons during the lab will be applied, and the system will be in a fresh state for evaluation. With the serverb machine rebooted, I am now ready to evaluate the lab results and verify the status of the services and daemons according to the specifications provided.

Conclusion

In this chapter, we learned about Control Services and Daemons. We explored how to list system daemons and network services that were started by the systemd service and socket units, how to control and monitor network services and system daemons with the systemd service, and how to configure several services to be enabled or disabled, running or stopped, based on a specification that was provided to us. Through the lab exercises, we were able to practice starting, stopping, enabling, and disabling services such as psacct **and rsyslog, and rebooting the system to apply any changes made. By mastering these skills, we can effectively manage and control the services and daemons running on our system, ensuring optimal performance and security.