🌐 🇵🇱 Polski · 🇬🇧 EN
In every operating system, the ability to manage running services and daemons is a crucial aspect. System stability and reliability depend on the ability to manage and configure services. Services may malfunction due to very simple reasons, such as an incorrectly set system time, or due to something more complex, like sharing a file in a network environment for users using NFS. Knowledge of service management is a large part of the Red Hat exam and is also a critical skill for an administrator in real-world work with Linux environments. In Linux, services are also called daemons. The reason some services are named this way is that a single service is actually composed of many other daemons. For example, NFS. Usually, a service we call a daemon is a service whose name ends with the letter "d". For example, the SSH service is a service named "sshd", or the Apache web server is named "httpd".
Let's see what differences in running services exist between individual runlevels. Let's start with mode 3 (runlevel 3 - text mode):
# ls /etc/rc.d/rc3.d/
The contents of this directory are symbolic links to scripts in the system, usually located in # /etc/rc.d/init.d.
If we take a look, most links have a syntax resembling: # [K | S]XXservice_name. One can guess that this refers to "K" for "Kill" and "S" for "Start", and "XX" denotes a number between 01 and 99, including duplicates. So these are service names. The digits indicate the order in which services start after entering a given mode, for example, the services S10network and S55sshd, where it is logical that the network must be up first, after which one can communicate via SSH. The same applies to stopping processes. That is, starting and stopping in order according to the dependencies of one service on another. Therefore, one must pay special attention when editing the contents of runlevel directories (rc.d), because if the order of starting or stopping dependent services is not maintained, it can lead to unpredictable system behavior or the shutdown of certain services.
Now that we know the differences between services started and stopped in different runlevels, we can see how the management tool used for enabling or disabling selected services for a given runlevel works. Imagine we have to make an entry in the previously mentioned services, i.e., S10network and S55sshd, for all runlevels, which means 2x6 = 12 locations where changes must be made. And what if we had to change something in all services? How long would that take? It is easier to manage services across all runlevels using the chkconfig tool.
Syntax of the chkconfig command: # chkconfig [options] service_name
chkconfig options (Use two dashes before attributes.):
- -- list service_name - Shows the status of the service in all runlevels
- -- add service_name - Adds the service to be managed by chkconfig
- -- del service_name - Removes the service from chkconfig management
- -- level level_number - Enables or disables the service at a given runlevel
- service_name on | off | reset - Enables or disables the service at levels 2-5
Task 1
What is the status of the SSH service at which level?
Ans: # chkconfig --list sshd as a result we get:
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
The result obtained is very simple to interpret. The service is started in levels 2, 3, 4, 5 and stopped in levels 0, 1, and 6.
Task 2
How to stop the SSH service from starting at all levels?
Ans: # chkconfig sshd off then we check what the status looks like after the change # chkconfig --list sshd :
sshd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Now the sshd service will not start at any level.
Task 3
Allow the service to start at the levels it was previously enabled on.
Ans: # chkconfig sshd on and to verify # chkconfig --list sshd :
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Task 4
Disable the sshd service at level 4
Ans: # chkconfig --level 4 sshd off and to verify # chkconfig --list sshd :
sshd 0:off 1:off 2:on 3:on 4:off 5:on 6:off
Besides using the chkconfig command, we also have a graphical tool available, which is launched by running the ntsysv command. The only difference between the tools is the fact that ntsysv provides a menu with a list where we can select or deselect chosen services.
# cat control-alt-delete.conf
# control-alt-delete - emergency keypress handling
#
# This task is run whenever the Control-Alt-Delete key combination is
# pressed. Usually used to shut down the machine.
start on control-alt-delete
exec /sbin/shutdown -r now “Control-Alt-Delete pressed”
You can see where the input for this task comes from, i.e., pressing the Ctrl+Alt+Delete keys. Exec defines the command that will be executed then. Besides tasks, let's also see the definition of an event:
# cat ck-log-system-start
# Upstart event
# ck-log-system-start - write system start to log
#
start on stopped rcS
console output
exec /usr/sbin/ck-log-system-start
This event creates a log file recording the moment when the system is started correctly. At this point, one might wonder how to trigger a task or event? For this, we use a command similar to service: initctl
Syntax of the initctl command: # initctl [command]
Options for initctl:
# ntsysv - the tool applies to the level in which it was called
# ntsysv -- level 2 - the tool applies to runlevel 2
Of the above solutions, the chkconfig command is faster to operate, but we have a choice and can use the graphical version, ntsysv. At this point, we already know how to enable and disable selected services at individual runlevels. But what to do when the system has already started, and you happened to forget to start a selected service? Do you have to add it with chkconfig and restart the system again? Well, there is no such need, because we have the # service command, thanks to which we can start, stop, and check the status of selected services.
Syntax of the service command:
# service ( -- status-all | service_name attribute [start|stop|restart|status])
# service ( -- status-all | service_name attribute [start|stop|restart|status])
Task 1
Usually, it is a good idea to check the status of a given service first. Check the status of the ntpd service?
Ans: # service ntpd status as a result we get ntpd is stopped
Task 2
If the service is not running, start it
Ans: # service ntpd start the result will be: Starting ntpd [OK]
If everything is fine, we will see OK at the end of the line or FAIL if something goes wrong.
Task 3
Stop the NTPD service
Ans: # service ntpd stop as a result: Shutting down ntpd: [OK]
UPSTART - NEW TOOL IN RHEL6
As mentioned earlier, in RHEL6 a new solution called "Upstart" appeared, which uses "tasks" and "events" to start various services. The biggest problem when working with Upstart is the fact that there is no standard, exact location where configuration files are stored. More precisely, you can search for a given task in the /etc/init location and find a given event in /etc/event.d, and traditional SysV Init directories still exist as well. With the release of Upstart, several services were moved to this tool, e.g., the Syslog service responsible for system logs. Each task can use events that trigger other tasks. An example will explain this best:
# control-alt-delete - emergency keypress handling
#
# This task is run whenever the Control-Alt-Delete key combination is
# pressed. Usually used to shut down the machine.
start on control-alt-delete
exec /sbin/shutdown -r now “Control-Alt-Delete pressed”
You can see where the input for this task comes from, i.e., pressing the Ctrl+Alt+Delete keys. Exec defines the command that will be executed then. Besides tasks, let's also see the definition of an event:
# cat ck-log-system-start
# Upstart event
# ck-log-system-start - write system start to log
#
start on stopped rcS
console output
exec /usr/sbin/ck-log-system-start
This event creates a log file recording the moment when the system is started correctly. At this point, one might wonder how to trigger a task or event? For this, we use a command similar to service: initctl
Syntax of the initctl command: # initctl [command]
Options for initctl:
- start - Start a task
- stop - Stop a task
- restart - Restart a task
- reload - Send HUP signal to a task
- status - Query task status
- lists - List known tasks
- emit - Trigger a task
By using the initctl command, you can see exactly what tasks are being performed by our system
# initctl list
With subsequent system releases, more and more services are coming under the control of the new tool, which is Upstart.
If you are reading this course in order, at this point your knowledge should be expanded with topics regarding the GRUB bootloader, system services, and their management. These topics are repeated many times in the Red Hat Prep Guide, which is a clear sign that this is knowledge you should focus on.
If you are reading this course in order, at this point your knowledge should be expanded with topics regarding the GRUB bootloader, system services, and their management. These topics are repeated many times in the Red Hat Prep Guide, which is a clear sign that this is knowledge you should focus on.
Comments