Controlling System Startup Processes
Red Hat Enterprise Linux (RHEL) is a rock solid commercial grade Linux operating system. If you're interested in learning RHEL from a system admins perspective then this course is for you!
The "Red Hat Enterprise Linux Technical Overview" course walks you through many of the basic system admin tasks and concepts required to administer RHEL effectively.
This course will provide you with insights to:
- Working with the Terminal
- Understanding the Kernel and User Spaces
- Graphical User Interface
- File management and the File System Hierarchy
- Editing Files using Vim
- Organizing Users and Groups
- File Permissions
- Managing Software
- Configuring Networking
- Controlling System Startup Processes
- Introduction to Containers
- Overview of Cockpit
Hey guys you may have heard about systemd and systemd is the heart of your Linux system.
And it's responsible for the initialization of your system, management of various resources like daemons, processes, pods, and more.
Now how you interface with it is by using the system ctl command.
And then you would refer to a unit.
Now a unit is an aspect of the system that systemd manages.
And we've various types of units. We have service units that are used for daemons. We have socket units for tcp ports. We have path units to manage files and directories. We have target units as well which are groups of other units.
Now every unit is represented by a unit file that has its configuration.
Now to list the different unit files that we have, we can make use of the command systemctl and we could say list-unit-files.
And again, take advantage of tab-completion over here.
So we're going to do a list for unit files.
And you can see these are the different unit files that we have. Now the extension typically is indicative of the type of unit that we are dealing with over here.
So you can see that we have things like mounts, we have automounts, we have paths, services, those are big ones we deal with them quite frequently.
Scrolling down in the list over here, lots of services as you can see.
But there also others like sockets. So you can see that we have a cockpit.socket right now.
And then further towards the bottom you can see targets. Like I said think of a target as being a group of other units.
Now typically to do management of services again we would make use of systemctl. If we want you to display units of a particular type we could say systemctl and we could say list-units.
So we're going to be listening the units of a particular type. So now we could say --type and we could specify the type that we're interested in.
So we could say service and it's only going to show us unit types or unit files of the type service right now.
So again you can see we have a couple of components over here.
Let's go and scroll down through the list. Yeah, the big one that we're going to deal with is sshd.service.
So let's go and run that systemctl command to have a look at the status of the sshd service.
So the command right now becomes systemctl status sshd.
Now what I could do is specify the full name of the units including the the extension.
So I could say sshd.service.
And that's completely optional. The command would work without it. So it would yield the same result. So what we can see right now is that we are having a look at the units called sshd.service which is for the open ssh server daemon.
You can see that it's unit file is loaded and you can see the path that the unit file comes from. So this unit file comes from /usr/lib/systemd/system/shd.service.
And like I said it's a configuration file. It's currently enabled.
And what this means is that whenever the system boots up, that unit file is going to be initialized. That service in other words is going to be started.
And you can see that the vendors preset behavior is for it to be enabled.
At the moment, it's currently running. So we could see its active status over there.
It's currently running right now and you can see since when, since Wednesday April the 17th.
It also gives us some really cool information about the applicable documentation that you may be interested in.
So it's referring us over here to man pages.
We can see the main process ID as well we can see the the tasks, the memory. We can see something about c groups or control groups.
And here we have some basic logging information that is displayed over here.
Now what I'm going to do is that I'm going to go along and I'm going to restart sshd. So to do that I'm going to say systemctl restart sshd.
Now I want you to just to be mindful of the main process ID over there 728.
So let's go and restart sshd.
And now we're going to have a look at the status once again.
So when you use the restart command against a service unit file, what's going to happen is that the the service would be stopped and it would be started again.
And this means that it would get a brand new process ID. As opposed to doing a reload operation.
So let's going to try the reload operation.
So again let's just remind ourselves that the main process ID right now is 1391.
So we're going to say systemctl reload sshd.service.
And again the dot service is completely optional.
I've got there that quickly because I use tab completion. So let's go and have a look at the status one more time. And guys what we can see over here is that the main process ID has remained same. Now the reason why you may want to do a reload of a service is that you may have changed the configuration file that is associated with that service. So let's just say you come along and you want to change how your service behaves.
You've changed the configuration file.
You see when that service initially started, it took the configuration file from the file system and it put it into memory. And now it uses the version of the configuration file from memory. Now in the meantime, what you've come along and done is that you've edited the configuration file on the file system.
Now in order to get those changes to be used by your service what we need to do is that we need to tell the service to go and reload its configuration file.
So when we said systemctl reload, we told the service: Hey service! Dump your configuration file that you're making use of right now, go and reload the configuration file from the file system into memory and now it would use that newly modified version. Now what you did when you did a restart is that you terminated the service. And when you terminate the service, so when you stop the service it would dump its configuration file which is in memory.
Then the restart action would result in the service being started up again.
And like I said when a service starts up it would go and load its configuration file from the file system, loaded up into memory and now it would use the version of the configuration file that is in memory. So some of the more basic tasks that you need to be familiar with is how you would go about starting a service and how you would go about enabling the persistent starting of a service.
So to do that you would say systemctl and you would say start and you would specify the service by name. So I would go and say something like sshd. If you want to make sure that the service is persistently enabled, you would say systemctl enable sshd.
And that will make sure that whenever your system boots up, whenever a systemd initializes that sshd is enabled it is started.
So looking at the status over here guys you can see that it's active, it's running and should I reboot the system. It will be started again automatically for me. So again these are some of the more basic things that you need to be mindful of when working with systemd. And systemctl in particular is your interface, it's your gateway into into operations in the world of systemd.
So with that guys we are going to bring things to a close over here, I will see you in the next video.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.