Let's examine how to manage startup processes and services
in Linux.
When we boot up Linux, certain important applications start up automatically,
some of them even start up in a specific order.
For example,
if APP two depends on APP one, then app one will load before app two.
All of this magic happens behind the scenes and in a rather intelligent way.
Furthermore, if important applications crash,
they will be restarted automatically.
This way the system can continue to run smoothly
even if there's a small hiccup like this.
But how does all this happen?
Well,
with the help of what is called the init system short for initialization system.
So how does this
init system know how to start up applications,
what to do when a program crashes and so on?
It needs specific instructions to know how to do its job.
And sure enough,
it has all the instructions it needs in what are called systemd units.
These are simply text files that describe the necessary logic
and system D is the name of a collection of tools,
components and applications that help start operate and
manage most of the Linux based operating systems.
System D is also the name of the program that starts up as the
init system, which can be a bit confusing.
Long story short system D is the name of a large collection of tools and components,
but also the name of the application responsible for system initialization
and monitoring the system as a whole to ensure smooth operation.
Now, units can be of various types such as service socket device, timer and others.
For example timer units,
let us tell the init system that it
should launch a specific application once per week.
Maybe to clean up some files or verify a database
units can be of various types such as service,
socket device, timer and others.
For example, timer units,
let us tell the init system that it
should launch a specific application once per week,
maybe to clean up some files or verify a database.
But we'll be looking at service units in this lesson.
Now service units have clear instructions about such things as
what command to issue to start up a program.
What to do if a program crashes,
what command to issue when a program is restarted. And many other things
in a nutshell,
a service unit tells the init system all it needs to know
about how it should manage the entire life cycle of an application.
We can see the multitude of instructions we can add in
a service unit if we type in man systemd dot service.
Now let's look at a real example,
servers need to run the SSH daemon to
let users connect to them from remote locations.
And there's a service unit that instructs the init system about
how to start this daemon and how to keep it running.
We can look at this service file with this command
and we'll see lines like this in this file. Execstart tells the
init system what command it should run when it wants to start the SSH daemon.
Execreload tells it what command it should run
to reload the configuration for the SSH daemon.
We'll see an example of what reloading a service means later in this lesson.
And then the restart line tells system D to
automatically restart this process only when something fails.
For example, if the SSH daemon crashes, it's a good idea to have system D restart it.
So we can still connect to our server.
Now, if we want to edit this service file and modify these instructions,
we can use a command like this.
If we want to cancel our edits later and
return the service file to its factory default settings,
we can use this command
and revert it back.
So this systemd service is responsible for the life cycle of the SSH daemon
to start up the SSH server application, restart it when needed and so on
to see the status of the service, we can run this command
system CTL status SSH service. Now, this shows us a few interesting things.
And here are the most important.
We can see if this service is enabled,
if it's enabled.
That means that system D will automatically start up the SSH daemon.
When the system boots
disabled means it won't automatically start up,
but it still can be manually started by the administrator.
And we'll see how later on
next. We can see if the program managed by the service is running.
If it's currently launched, loaded into memory and running,
we'll see a status of active running,
we could potentially encounter situations where the service is active,
but the program managed by the service is not running
because it was launched, did its job successfully and then exited.
In such a case, we'd see a status of active but exited between parentheses.
Now, if the SSH daemon is currently running,
we'll also see its P ID or process identifier.
Every time we launch a program on Linux, a process will start up
the process encapsulates the computer code and resources that are loaded
into memory and using the CPU when it needs to execute instructions
and every process has this unique number, identifying it.
The pit can be used to interact with this process
as we'll see in one of the next lessons.
And we can also see the exact command that has been used to start up this process.
And finally, system CTL status shows us a few log lines,
status and error messages generated by this application.
This can be useful to see what happened after the program started up.
If it encountered any errors and what settings are active and so on, we can press Q
to exit from the status display.
Now to stop a service, we can enter SYSTEMCTL stop and then the service,
this will close the program that the service unit controls.
We mentioned how some services do not automatically start up at boot time,
but they can still be manually started up later.
The command to manually start a service
is system CTL start and then the service.
Now sometimes we will change the settings of a program,
for example, to modify how the SSH daemon works.
We could change its settings in the file at Etsy SSH, SSH D underscore config.
Now, after we change a configuration file like this,
the process currently running will still use
the old settings until it's restarted.
One way to force the process to restart and
pick up the new settings is with this command
system CTL restart SSH service.
However, this restart command can sometimes be a bit disruptive.
For example, if a few users are actively using that program,
the restart may interrupt their work.
So there's a more gentle way to reload program
settings without completely closing and reopening the application.
And that's what system CTL reload.
Now, if we would check out the status for the SSH service again,
we would see that the first command restarted it
and the second just gracefully reloaded its settings.
It's worth noting that not all applications support being reloaded like this,
but we have a command that can automatically try
a graceful reload first and then a restart.
If the reload is not supported by that app,
we can do that by typing in system CTL reload or restart
and the service.
Now, if we want to disable SSH logins completely,
we could prevent the SSH daemon from automatically starting up a boot time
by typing in system CTL disable in the service.
And now if we check the status, it's disabled, but we can also check with
system CTL is enabled
now to reenable the SSH daemon and make it automatically start up at boot.
We would type in system CTL enable in the name of the service.
Quick note, if you went through these steps on your own virtual machine,
if you disabled your SSH service,
please reenable it now to ensure that you can log
back in the next time you boot your Linux OS.
Now, usually after we install a new application,
especially if it's a daemon or a server of some kind,
like a database or server application or a web server, we want to do two things.
We want to enable it to autostart every time the operating system boots up
and we want to manually start it so we can begin to use it immediately.
Operating systems from the Debian and
Ubuntu family usually take these steps automatically after you
install certain programs operating systems from the Debian and
Ubuntu family usually take these steps
automatically after you install certain programs.
But other operating systems, for example,
those belonging to the Redhat family don't.
So it's useful to know how to perform these actions manually.
One way to do this is with the two commands that we just showed.
First,
we tell our init system to automatically start the
service every time the operating system boots up.
Then we tell our init system to also start the service immediately.
Otherwise this service will only start the next
time we boot up the operating system,
but it would not run for our current session.
But we also have an alternative command that does both things in one shot.
The dash dash. Now, option tells system CTL to both enable the service
and autostart every time the system boots up but also start the service. Now,
the disable command also supports the dash dash. Now option
if you're practicing in a virtual machine,
don't enter this next command as you won't be able to log in through SSH anymore.
This would disable the SSH daemon from automatically starting up when the system
boots up and also stop the service in the program it manages.
Now with some services, we might notice that they're stubborn.
That is even if we disable them from autostarting at boot and we stop them,
we might notice later on that they're still running somehow.
They mysteriously start up on their own.
And we'd be left wondering, well, how does this happen?
Well,
some services could automatically start up other services if they want to do so.
So there can be a domino effect service.
One can start up service two, even if you disabled and stopped service two.
But there's a brute force way to prevent this from happening.
And it's called masking.
Let's say we want to mask the service responsible for managing the at daemon.
The at daemon is a program that lets us schedule tasks we want to run in the future
and failed to start service.
So this basically ensures that the service cannot ever be started
even if other programs users or services want to do.
So
finally,
if we mask the service and we want to cancel that
we can unmask it and return to normal with this command
system, CTL unmask.
But we can see that the system CTL commands are rather intuitive.
What might not always be intuitive is how a
service for a certain application might be named.
For example,
we can install a web server like Apache and expect the
service for this application to be called Apache dot service.
But we may find out that it's called HTTP D dot service on some operating systems.
So it can be useful to get a list of all service
units available on the system no matter if they're currently enabled,
disabled, started or stopped and we can do that with this command
system CTL list units type service,
all system CTL units would show all types of systemd units.
And remember besides service units, other types exist like socket units,
timer units, et cetera.
With dash dash type service. We tell our command to only show us service units
combined with dash dash
all, we tell it to show us all service units no matter what their status is.