Managing system services with systemd
105
Rationalizing how services start so that only those that are required are started is a good way to accomplish efficiency—for example, there
is no need to start Bluetooth, printer, or network services when the system is disconnected, there is no Bluetooth hardware, or no one is printing. With fewer
services waiting to start, the system boot is not delayed by those waits and focuses on the ones that really need attention.
On top of that, parallel execution allows us to have each service taking the time it needs to get ready but not make others wait,
so in general, running services initialization in parallel allows us to maximize the usage of the
central processing unit (
CPU), disk, and soon, and the wait times for each service are used by other services that are active.
systemd also pre-creates listening sockets before
the actual daemon is started, so services that have requirements on other services can be started and be on await status until their dependencies are started. This is done without them losing any messages that are sent to them, so when the service is finally started, it will act on all pending actions.
Let’s learn a bit more about systemd as it will be required for several operations we’re going to describe in this chapter.
systemd comes
with the concept of units, which are nothing but configuration files. These units can be categorized as different types, based on their file extension, as illustrated in the following screenshot:
Table 4.1 –
systemd unit types description Tools for Regular Operations
106
Share with your friends: 
