mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-09-04 04:41:36 +00:00
190 lines
7.2 KiB
ReStructuredText
190 lines
7.2 KiB
ReStructuredText
.. _restart:
|
|
|
|
Restart system services after an OS update
|
|
##########################################
|
|
|
|
The software life cycle describes how software is created, developed, and
|
|
deployed, and includes how to replace or update software. A good OS
|
|
provides tools for the entire software life cycle. These tools must include
|
|
ways to remove software components properly when replaced with something
|
|
else.
|
|
|
|
Most of the work on software update code in |CL| was focused on adding new
|
|
software to the system. We recommended that users reboot their system once in
|
|
a while, but we did not provide any tools to restart services easily, until
|
|
now.
|
|
|
|
User challenges
|
|
***************
|
|
|
|
It is difficult to determine which services to restart. You can either
|
|
evaluate each system and reboot manually, or figure out which services to
|
|
restart based on documentation like the |CL| release notes. Since neither
|
|
option solves the issue completely, the |CL| team created a solution.
|
|
|
|
Over the years, several OSes approached the problem and created partial
|
|
solutions such as the following:
|
|
|
|
* Automatically restart services during an upgrade.
|
|
* Evaluate services using these steps:
|
|
|
|
* Mark updates requiring a reboot, such as kernel updates.
|
|
* Inform the user of those updates.
|
|
* Ask the user to restart the OS.
|
|
|
|
Both solutions are acceptable for many OSes. However, |CL| updates software
|
|
automatically and users do not see notices from the updater unless they
|
|
review the journal. |CL| requires a completely different solution, with the
|
|
following requirements:
|
|
|
|
* Eliminate the guesswork about what to restart and under what circumstances.
|
|
* Cannot restart everything. Many service daemons do not support an automatic
|
|
background restart.
|
|
* Fit into the |CL| architectural perspective: be small, quick, and lean.
|
|
|
|
clr-service-restart functionality
|
|
*********************************
|
|
|
|
Typical reasons to restart a service daemon include:
|
|
|
|
* A new version replaces the executable file itself.
|
|
* A new version replaces a library component used by a service daemon.
|
|
|
|
Our method restarts daemons when it is really needed, especially
|
|
in the case of security updates. The tool restarts daemons by reading
|
|
various files in the :file:`procfs` filesystem provided by the kernel.
|
|
|
|
The second part of the problem is to determine whether or not running
|
|
processes are part of a system service. The tool focuses on system services
|
|
because most system services are background tasks with no direct user
|
|
interaction. Fortunately, :command:`systemd` provides a simple way to:
|
|
|
|
* Determine which active tasks are within the system domain.
|
|
* Determine which tasks map to which service.
|
|
|
|
We combined both solutions into a low-overhead tool that shows which system
|
|
daemons require a restart, as shown below:
|
|
|
|
Figure 1: Invoke :command:`clr-service-restart`.
|
|
|
|
.. code-block:: bash
|
|
|
|
sudo clr-service-restart -a -n
|
|
|
|
.. code-block:: console
|
|
|
|
upower.service: needs a restart (a library dependency was updated)
|
|
/usr/bin/systemctl --no-ask-password try-restart upower.service
|
|
NetworkManager.service: needs a restart (a library dependency was
|
|
updated)
|
|
/usr/bin/systemctl --no-ask-password try-restart NetworkManager.service
|
|
....
|
|
|
|
:command:`clr-service-restart` implements a whitelist to identify which
|
|
daemons can be restarted. The system administrator can customize the default
|
|
|CL| OS whitelist using *allow* or *disallow* options for
|
|
restarting system services. When a software update occurs,
|
|
:command:`clr-service-restart` consults the whitelist to see if a service
|
|
daemon is allowed to be restarted or not. See the options section for
|
|
details.
|
|
|
|
|
|
Options for clr-service-restart
|
|
*******************************
|
|
|
|
The *allow* option identifies a daemon to restart after an OS software
|
|
update. The :command:`clr-service-restart` daemon creates a symlink in
|
|
:file:`/etc/clr-service-restart` as a record. The example below tells
|
|
:command:`clr-service-restart` to restart the *tallow* daemon after an
|
|
OS software update.
|
|
|
|
.. code-block:: bash
|
|
|
|
sudo clr-service-restart allow tallow.service
|
|
|
|
The *disallow* option tells :command:`clr-service-restart` not to
|
|
restart the specified daemon even if the OS defaults permit the daemon to be
|
|
restarted. The :command:`clr-service-restart` daemon creates a symlink in
|
|
:file:`/etc/clr-service-restart` that points to :file:`/dev/null` as a
|
|
record. The example below tells :command:`clr-service-restart` not to
|
|
restart the *rngd* daemon after an OS software update.
|
|
|
|
.. code-block:: bash
|
|
|
|
sudo clr-service-restart disallow rngd
|
|
|
|
The *default* option makes :command:`clr-service-restart` revert back
|
|
to the OS defaults and delete any symlink
|
|
in :file:`/etc/clr-service-restart`. The example below
|
|
tells :command:`clr-service-restart` to restart *rngd* automatically again,
|
|
because *rngd* is whitelisted for automatic service restarts by default
|
|
in |CL|.
|
|
|
|
.. code-block:: bash
|
|
|
|
sudo clr-service-restart default rngd
|
|
|
|
Monitor options for clr-service-restart
|
|
=======================================
|
|
|
|
:command:`clr-service-restart` works in the background and is invoked with
|
|
:command:`swupd` automatically. Review the journal output to verify that
|
|
services are restarted after an OS software update.
|
|
|
|
To monitor :command:`clr-service-restart`, use one or both options described
|
|
below.
|
|
|
|
.. option:: -n
|
|
|
|
This option makes :command:`clr-service-restart` perform no restarts.
|
|
Instead it displays the services that could potentially be restarted.
|
|
When used, :command:`clr-service-restart` outputs a list of messages
|
|
showing:
|
|
|
|
* Which service needs a restart.
|
|
* What unit it is.
|
|
* Why it needs a restart.
|
|
* Which command is required to restart the unit.
|
|
|
|
.. option:: -a
|
|
|
|
This option makes :command:`clr-service-restart` consider all system
|
|
services, not only the ones that are whitelisted. Because the default
|
|
whitelist in |CL| is relatively short, you can use this option to
|
|
restart all impacted services when you log in on the system.
|
|
|
|
If you pass both options (:option:`-a` and :option:`-n`),
|
|
:command:`clr-service-restart` displays a complete list of system services
|
|
that require a restart. Use both options to verify that all desired daemons
|
|
are restarted.
|
|
|
|
|
|
Telemetry
|
|
*********
|
|
|
|
:command:`clr-service-restart` may cause problems such as a short service
|
|
outage when a daemon is being restarted, or if a daemon fails to properly
|
|
restart. To minimize issues, :command:`clr-service-restart` creates a
|
|
telemetry record and sends it to the optional |CL| telemetry service if both
|
|
conditions below are met:
|
|
|
|
* If a unit fails to automatically restart after an OS update.
|
|
* If that unit resides in the system
|
|
location :file:`/usr/lib/systemd/system`.
|
|
|
|
If you do not install the |CL| telemetrics bundle, the data is discarded. If
|
|
you install the telemetrics bundle and you opt to send telemetry, then the
|
|
system unit name is sent to the |CL| telemetry service. We evaluate the
|
|
report and update the whitelist to remove services that are not safe to
|
|
restart.
|
|
|
|
Conclusion
|
|
**********
|
|
|
|
The |CL| team enjoys coming up with simple and efficient solutions to make
|
|
your work easier. We made a github project of :command:`clr-service-restart`
|
|
and we invite you to look at the code, share your thoughts, and work with us
|
|
on improving the project. You can find the project at:
|
|
|
|
https://github.com/clearlinux/clr-service-restart
|