In this lesson,
we're going to cover the concept of services
in the Linux operating system.
Now, services are programs or processes
that run in your servers at all times,
usually, from the time you boot up the server
until you shut it down.
These services are used to provide persistent support
for requests and monitoring
from other processes or from external clients.
Some examples of well-known services are Apache
for running a web server
and Postfix for running an email server.
Just like any other components of Linux though,
services can be managed as well.
If you're a system administrator,
you're going to be dealing with services regularly.
If you're a normal desktop user though,
you may come across the need to restart
or perform operations to run services as things go wrong.
In this lesson, you're going to learn how to start, stop,
and restart services in any Linux distribution.
Now, most services are implemented in the form of daemons,
which are running programs that operate in the background
without the need for human intervention,
which means that daemons are going to lie dormant
until an event triggers them
to take some kind of function or activity.
Now, the init system is the first process
that starts outside of the kernel,
and it's generally going to be the backend service
that controls when and how other services
are going to be started.
The init daemon refers to a configuration file
and initiates the processes that are listed in that file.
This prepares your system
to run the required software for you.
The init daemon is going to run continuously
until the system is powered off.
And the programs on your system are not able to run
without the init daemon.
In Linux, you can initialize the system
through SysVinit and systemd.
The method that's going to be active
on your Linux system is going to affect
how you manage services on that system.
For example, if you use the systemd software suite,
it's going to provide for an init method
for initializing the system.
It's also going to provide for tools for managing services
on that system that derive from the init daemon.
The systemd suite was designed as a replacement
for other methods like SysVinit
and is now the dominant init method that's used
in modern Linux distributions.
The systemd suite is going to offer several improvements
over older methods as well.
For example, it supports parallelization,
like starting programs at the same time for quicker boot up
and reducing shell overhead.
In systemd, control groups are also used to track processes
instead of process IDs, or PIDs,
which provides a better isolation
and categorization for all of your processes.
Now, systemd is going to use unit files
to determine how it's going to handle units,
which are system resources that systemd can actually manage.
Resources can include network services,
block storage devices, peripheral devices,
file systems, and many others.
Daemons are going to access
and manage all of these different resources for you,
and unit files can also be used
to set system environment variables and parameters
as well as which values are going to be passed
from a parent process to a child process that it creates.
By adding directives for an environment variable,
you're going to be able to make it easier for a service
or other unit to work with custom values as well.
In systemd, targets are a method
of grouping unit configuration files together, typically,
in order to represent specific modes of operations.
Each dot target file is going to be used
to determine one of several ways
in which the system can operate,
such as running with just a command line environment,
running with a graphical desktop environment,
initiating a system shutdown, and many others.
Therefore, you can activate a target in order to boot
into a desired environment if you want to.
Now, another command we need to talk about
is systemctl, or system control.
The system control command enables you
to control the systemd init daemon,
and you can view running services,
enable and disable services to run at boot
or in the current session,
and you can determine the status of these services
as well as managing the system target.
You can do all of this through various subcommands
that are issued along with the systemctl command,
including status service, which is going to be used
to retrieve the current status of a given service,
enable service, which is used to enable a service
to be started on boot, disable service,
which is going to be used to disable a service
so it no longer is started up on boot, start service,
which is used to activate a service immediately,
stop service, which is used
to deactivate a service immediately, restart service,
which is used to restart a service immediately,
set-default target, which is used to set the default target
for the system to be used on boot,
isolate target, which is used to force the system
to immediately change the provided target, mask unit file,
which is used to prevent the provided unit file
from being enabled or activated
even when it's done manually, and daemon-reload,
which is used to reload the systemd init daemon,
including all of the unit files.
To run the system control command,
type in systemctl, space, the options, space,
the subcommand, space, and the arguments.
The system control command
has many different options you can use,
including -t unit file type, which is an option that's used
to specify the unit file type to perform the operation on.
The -a option is used to list all the unit files
or properties regardless of their state.
The dash no-reload option is used
to prevent the reloading of configuration changes
when enabling or disabling a service.
The --no-ask-password option is used
to prevent users from being asked to authenticate
when they're performing privileged operations.
The --runtime option is going to be used
to make changes temporary,
this way they won't be present after you reboot the system.
The -H remote host option is going to be used
to execute the operation on a remote host
that's specified by its host name or IP address.
And the --no-pager option is used to prevent the output
from being piped into a paging utility.
There are lots of different instances
when a system administrator needs to work in a GUI
for a short period of time,
and you can do this by using the systemctl command
to change your target.
Now, it's common to configure a Linux server
to boot up by default to the command line environment.
And you do this by using the multi-user dot target file.
An administrator though might want to switch
to the graphical user environment,
which is known as the graphical dot target file.
And we can do this for a particular task.
And then we can switch the server back
to the multi-user dot target file when the task is complete.
The system administrator would then leave the server
in a more efficient command line configuration
after the task is completed,
which lowers the resources required to run that server
instead of leaving that graphical user interface
up and running.
In most cases, the systemctl command
is going to be used to control services,
but there are some additional systemd commands
that you can also use too.
For example, hostnamectl will enable you
to view the system's network host name
and other information about the system's hardware
and the Linux kernel it's running.
You can also use the command
to change the system's host name.
To run this command, type hostnamectl, the options,
the subcommand, and the arguments.
For example, if you want to set your host name to server01,
you need to enter hostnamectl, space, set-hostname, space,
server01 at the command line, and then hit enter.
Now, earlier I mentioned System V init,
which is an older init method
that has largely been replaced by systemd.
However, some distributions
will still support System V init.
Just like systemd,
SysVinit is going to provide you with various tools
to manage services and the state of the system.
Now, one of the major differences between systemd
and System V init is that System V init uses runlevels.
They control the state of the operating system
in much the same way that systemd targets are going to be used.
And they're going to determine
what type of daemons should be running
in order to create a specific type of environment for you.
In fact, the systemd targets were actually created
to map the existing runlevels.
When we use something like runlevel zero,
this shuts down the system.
Runlevel one starts up a single-user mode.
Runlevel two starts up a multi-user mode
without remote networking.
Runlevel three starts multi-user mode
with remote networking.
Runlevel four is not really used.
Runlevel five though starts multi-user mode
with networking and a graphical user interface capability,
and runlevel six is going to reboot your system.
Now, a single-user mode is going to boot the operating system
into an environment where the superuser must log in.
This means you're logging in as the root user.
Networking here is disabled in single-user mode,
and most partitions are not going to be mounted.
Typically, this is going to be used to troubleshoot issues
with networking or issues that prevent you
from booting into your normal multi-user environment.
The telinit command will enable you to switch
to the current runlevel of the system.
Now, on the systemd environments,
the telinit command is going to be translated
into the appropriate target request for you automatically.
The runlevel command will print the previous
and current runlevels of the system,
each one being separated by a space.
So to use the telinit command,
simply type in T-E-L-I-N-I-T, the options, and the runlevel.
Now, there is a special file on your system
if you're using a SysVinit system.
This is known as the slash E-T-C slash I-N-I-T-T-A-B file.
This is the inittab file,
and it's going to store details of various processes
related to your system initialization on a SysVinit system.
It's also going to store details
of the different runlevels that are in use.
The init daemon is going to read from this file
to determine what runlevel to boot into,
what daemons to start,
and what to do if the runlevel changes.
Every entry inside the /etc/inittab file takes the format
of id:rstate:action:process.
The id is just a unique identifier for that entry.
The rstate defines what runlevels they're going to apply to.
And the action specifies one of several tasks
that determine how SysVinit is going to handle the command
that's defined in the process field.
The /etc/init.d directory is going to store
all of your initialization scripts for all of your services.
These scripts control the initiation of services
in a particular runlevel.
The scripts are going to be invoked from the /etc/inittab file
when the system initialization begins
using different symbolic links that are found in that file.
SysVinit scripts are highly flexible
and can be configured according to the needs
of any given user.
The /etc/rc.local file is also going to be executed
at the end of the init boot process.
Typically, it's going to be used to start custom services.
However, this file is rarely used
and is not even supported in some distributions
that still use SysVinit.
Now, another command we need to talk about
is the check configuration command.
This is spelled C-H-K-C-O-N-F-I-G.
The check configuration command can be used
to control services in each runlevel.
It's also used to start or stop services
during system startup.
Some subcommands and options that can be used
with the check configuration command
to control your services include service on.
This is an option which is used to enable a service
to be started on boot.
Another one is service off.
This option is used to disable a service
so it's no longer started on boot.
Service reset is an option that's used
to reset the status of a service,
and the --level runlevel option is used
to specify the runlevel
in which to enable or disable a service.
To use this command, simply type in C-H-K-C-O-N-F-I-G,
the options, the service, and the subcommand.
Now, another command we have is the service command.
This is another way to control the SysVinit services
through the SysVinit scripts.
It's going to support various common subcommands
including service status,
which is used to print the current state of a service,
service start, which is used to start a service immediately,
service stop to stop a service immediately,
service restart to restart a service immediately,
and service reload to reread a service's configuration files
while the service remains running.
To run the service command, simply type in service,
the options, the service, and the subcommand.