In the first two articles in this series, I explored the Linux systemd startup sequence. In the first article, I looked at systemd's functions and architecture and the controversy around its role as a replacement for the old SystemV init program and startup scripts. And in the second article, I examined two important systemd tools, systemctl and journalctl, and explained how to switch from one target to another and to change the default target.
In this third article, I'll look at systemd units in more detail and how to use the systemctl command to explore and manage units. I'll also explain how to stop and disable units and how to create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
All of the experiments in this article should be done as the root user (unless otherwise specified). Some of the commands that simply list various systemd units can be performed by non-root users, but the commands that make changes cannot. Make sure to do all of these experiments only on non-production hosts or virtual machines (VMs).
One of these experiments requires the sysstat package, so install it before you move on. For Fedora and other Red Hat-based distributions you can install sysstat with:
dnf -y install sysstat
The sysstat RPM installs several statistical tools that can be used for problem determination. One is System Activity Report (SAR), which records many system performance data points at regular intervals (every 10 minutes by default). Rather than run as a daemon in the background, the sysstat package installs two systemd timers. One timer runs every 10 minutes to collect data, and the other runs once a day to aggregate the daily data. In this article, I will look briefly at these timers but wait to explain how to create a timer in a future article.
The fact is, systemd is more than just one program. It is a large suite of programs all designed to work together to manage nearly every aspect of a running Linux system. A full exposition of systemd would take a book on its own. Most of us do not need to understand all of the details about how all of systemd's components fit together, so I will focus on the programs and components that enable you to manage various Linux services and deal with log files and journals.
The structure of systemd—outside of its executable files—is contained in its many configuration files. Although these files have different names and identifier extensions, they are all called "unit" files. Units are the basis of everything systemd.
Unit files are ASCII plain-text files that are accessible to and can be created or modified by a sysadmin. There are a number of unit file types, and each has its own man page. Figure 1 lists some of these unit file types by their filename extensions and a short description of each.
|.automount||The .automount units are used to implement on-demand (i.e., plug and play) and mounting of filesystem units in parallel during startup.|
|.device||The .device unit files define hardware and virtual devices that are exposed to the sysadmin in the /dev/directory. Not all devices have unit files; typically, block devices such as hard drives, network devices, and some others have unit files.|
|.mount||The .mount unit defines a mount point on the Linux filesystem directory structure.|
|.scope||The .scope unit defines and manages a set of system processes. This unit is not configured using unit files, rather it is created programmatically. Per the systemd.scope man page, “The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.”|
|.service||The .service unit files define processes that are managed by systemd. These include services such as crond cups (Common Unix Printing System), iptables, multiple logical volume management (LVM) services, NetworkManager, and more.|
|.slice||The .slice unit defines a “slice,” which is a conceptual division of system resources that are related to a group of processes. You can think of all system resources as a pie and this subset of resources as a “slice” out of that pie.|
|.socket||The .socket units define interprocess communication sockets, such as network sockets.|
|.swap||The .swap units define swap devices or files.|
|.target||The .target units define groups of unit files that define startup synchronization points, runlevels, and services. Target units define the services and other units that must be active in order to start successfully.|
|.timer||The .timer unit defines timers that can initiate program execution at specified times.|
Fig. 1: Some systemd unit file types
I looked at systemd's startup functions in the second article, and here I'll explore its service management functions a bit further. systemd provides the systemctl command that is used to start and stop services, configure them to launch (or not) at system startup, and monitor the current status of running services.
In a terminal session as the root user, ensure that root's home directory ( ~ ) is the PWD. To begin looking at units in various ways, list all of the loaded and active systemd units. systemctl automatically pipes its stdout data stream through the less pager, so you don't have to:
[root@testvm1 ~]# systemctl UNIT LOAD ACTIVE SUB DESCRIPTION proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File> sys-devices-pci0000:00-0000:00:01.1-ata7-host6-target6:0:0-6:0:0:0-block-sr0.device loaded a> sys-devices-pci0000:00-0000:00:03.0-net-enp0s3.device loaded active plugged 82540EM Gigabi> sys-devices-pci0000:00-0000:00:05.0-sound-card0.device loaded active plugged 82801AA AC'97> sys-devices-pci0000:00-0000:00:08.0-net-enp0s8.device loaded active plugged 82540EM Gigabi> sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loa> sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loa> <snip – removed lots of lines of data from here> LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 206 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
As you scroll through the data in your terminal session, look for some specific things. The first section lists devices such as hard drives, sound cards, network interface cards, and TTY devices. Another section shows the filesystem mount points. Other sections include various services and a list of all loaded and active targets.
The sysstat timers at the bottom of the output are used to collect and generate daily system activity summaries for SAR. SAR is a very useful problem-solving tool. (You can learn more about it in Chapter 13 of my book Using and Administering Linux: Volume 1, Zero to SysAdmin: Getting Started.)
Near the very bottom, three lines describe the meanings of the statuses (loaded, active, and sub). Press q to exit the pager.
Use the following command (as suggested in the last line of the output above) to see all the units that are installed, whether or not they are loaded. I won't reproduce the output here, because you can scroll through it on your own. The systemctl program has an excellent tab-completion facility that makes it easy to enter complex commands without needing to memorize all the options:
[root@testvm1 ~]# systemctl list-unit-files
You can see that some units are disabled. Table 1 in the man page for systemctl lists and provides short descriptions of the entries you might see in this listing. Use the -t (type) option to view just the timer units:
[root@testvm1 ~]# systemctl list-unit-files -t timer UNIT FILE STATE chrony-dnssrv@.timer disabled dnf-makecache.timer enabled fstrim.timer disabled logrotate.timer disabled logwatch.timer disabled mdadm-last-resort@.timer static mlocate-updatedb.timer enabled sysstat-collect.timer enabled sysstat-summary.timer enabled systemd-tmpfiles-clean.timer static unbound-anchor.timer enabled
You could do the same thing with this alternative, which provides considerably more detail:
[root@testvm1 ~]# systemctl list-timers Thu 2020-04-16 09:06:20 EDT 3min 59s left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Thu 2020-04-16 10:02:01 EDT 59min left Thu 2020-04-16 09:01:32 EDT 49s ago dnf-makecache.timer dnf-makecache.service Thu 2020-04-16 13:00:00 EDT 3h 57min left n/a n/a sysstat-collect.timer sysstat-collect.service Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left mlocate-updatedb.timer mlocate-updatedb.service Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left unbound-anchor.timer unbound-anchor.service Fri 2020-04-17 00:07:00 EDT 15h left n/a n/a sysstat-summary.timer sysstat-summary.service 6 timers listed. Pass --all to see loaded but inactive timers, too. [root@testvm1 ~]#
Although there is no option to do systemctl list-mounts, you can list the mount point unit files:
[root@testvm1 ~]# systemctl list-unit-files -t mount UNIT FILE STATE -.mount generated boot.mount generated dev-hugepages.mount static dev-mqueue.mount static home.mount generated proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount disabled run-vmblock\x2dfuse.mount disabled sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount generated usr.mount generated var-lib-nfs-rpc_pipefs.mount static var.mount generated 15 unit files listed. [root@testvm1 ~]#
The STATE column in this data stream is interesting and requires a bit of explanation. The "generated" states indicate that the mount unit was generated on the fly during startup using the information in /etc/fstab. The program that generates these mount units is /lib/systemd/system-generators/systemd-fstab-generator, along with other tools that generate a number of other unit types. The "static" mount units are for filesystems like /proc and /sys, and the files for these are located in the /usr/lib/systemd/system directory.
Now, look at the service units. This command will show all services installed on the host, whether or not they are active:
[root@testvm1 ~]# systemctl --all -t service
The bottom of this listing of service units displays 166 as the total number of loaded units on my host. Your number will probably differ.
Unit files do not have a filename extension (such as .unit) to help identify them, so you can generalize that most configuration files that belong to systemd are unit files of one type or another. The few remaining files are mostly .conf files located in /etc/systemd.
Unit files are stored in the /usr/lib/systemd directory and its subdirectories, while the /etc/systemd/ directory and its subdirectories contain symbolic links to the unit files necessary to the local configuration of this host.
To explore this, make /etc/systemd the PWD and list its contents. Then make /etc/systemd/system the PWD and list its contents, and list the contents of at least a couple of the current PWD's subdirectories.
Take a look at the default.target file, which determines which runlevel target the system will boot to. In the second article in this series, I explained how to change the default target from the GUI (graphical.target) to the command-line only (multi-user.target) target. The default.target file on my test VM is simply a symlink to /usr/lib/systemd/system/graphical.target.
Take a few minutes to examine the contents of the /etc/systemd/system/default.target file:
[root@testvm1 system]# cat default.target # SPDX-License-Identifier: LGPL-2.1+ # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Graphical Interface Documentation=man:systemd.special(7) Requires=multi-user.target Wants=display-manager.service Conflicts=rescue.service rescue.target After=multi-user.target rescue.service rescue.target display-manager.service AllowIsolate=yes
Note that this requires the multi-user.target; the graphical.target cannot start if the multi-user.target is not already up and running. It also says it "wants" the display-manager.service unit. A "want" does not need to be fulfilled in order for the unit to start successfully. If the "want" cannot be fulfilled, it will be ignored by systemd, and the rest of the target will start regardless.
The subdirectories in /etc/systemd/system are lists of wants for various targets. Take a few minutes to explore the files and their contents in the /etc/systemd/system/graphical.target.wants directory.
The systemd.unit man page contains a lot of good information about unit files, their structure, the sections they can be divided into, and the options that can be used. It also lists many of the unit types, all of which have their own man pages. If you want to interpret a unit file, this would be a good place to start.
A Fedora installation usually installs and enables services that particular hosts do not need for normal operation. Conversely, sometimes it doesn't include services that need to be installed, enabled, and started. Services that are not needed for the Linux host to function as desired, but which are installed and possibly running, represent a security risk and should—at minimum—be stopped and disabled and—at best—should be uninstalled.
The systemctl command is used to manage systemd units, including services, targets, mounts, and more. Take a closer look at the list of services to identify services that will never be used:
[root@testvm1 ~]# systemctl --all -t service UNIT LOAD ACTIVE SUB DESCRIPTION <snip> chronyd.service loaded active running NTP client/server crond.service loaded active running Command Scheduler cups.service loaded active running CUPS Scheduler dbus-daemon.service loaded active running D-Bus System Message Bus <snip> ● ip6tables.service not-found inactive dead ip6tables.service ● ipset.service not-found inactive dead ipset.service ● iptables.service not-found inactive dead iptables.service <snip> firewalld.service loaded active running firewalld - dynamic firewall daemon <snip> ● ntpd.service not-found inactive dead ntpd.service ● ntpdate.service not-found inactive dead ntpdate.service pcscd.service loaded active running PC/SC Smart Card Daemon
I have pruned out most of the output from the command to save space. The services that show "loaded active running" are obvious. The "not-found" services are ones that systemd is aware of but are not installed on the Linux host. If you want to run those services, you must install the packages that contain them.
Note the pcscd.service unit. This is the PC/SC smart-card daemon. Its function is to communicate with smart-card readers. Many Linux hosts—including VMs—have no need for this reader nor the service that is loaded and taking up memory and CPU resources. You can stop this service and disable it, so it will not restart on the next boot. First, check its status:
[root@testvm1 ~]# systemctl status pcscd.service ● pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled) Active: active (running) since Fri 2019-05-10 11:28:42 EDT; 3 days ago Docs: man:pcscd(8) Main PID: 24706 (pcscd) Tasks: 6 (limit: 4694) Memory: 1.6M CGroup: /system.slice/pcscd.service └─24706 /usr/sbin/pcscd --foreground --auto-exit May 10 11:28:42 testvm1 systemd: Started PC/SC Smart Card Daemon.
This data illustrates the additional information systemd provides versus SystemV, which only reports whether or not the service is running. Note that specifying the .service unit type is optional. Now stop and disable the service, then re-check its status:
[root@testvm1 ~]# systemctl stop pcscd ; systemctl disable pcscd Warning: Stopping pcscd.service, but it can still be activated by: pcscd.socket Removed /etc/systemd/system/sockets.target.wants/pcscd.socket. [root@testvm1 ~]# systemctl status pcscd ● pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2019-05-13 15:23:15 EDT; 48s ago Docs: man:pcscd(8) Main PID: 24706 (code=exited, status=1/FAILURE) May 10 11:28:42 testvm1 systemd: Started PC/SC Smart Card Daemon. May 13 15:23:15 testvm1 systemd: Stopping PC/SC Smart Card Daemon... May 13 15:23:15 testvm1 systemd: pcscd.service: Main process exited, code=exited, status=1/FAIL> May 13 15:23:15 testvm1 systemd: pcscd.service: Failed with result 'exit-code'. May 13 15:23:15 testvm1 systemd: Stopped PC/SC Smart Card Daemon.
The short log entry display for most services prevents having to search through various log files to locate this type of information. Check the status of the system runlevel targets—specifying the "target" unit type is required:
[root@testvm1 ~]# systemctl status multi-user.target ● multi-user.target - Multi-User System Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor preset: disabled) Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago Docs: man:systemd.special(7) May 09 13:27:22 testvm1 systemd: Reached target Multi-User System. [root@testvm1 ~]# systemctl status graphical.target ● graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled) Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago Docs: man:systemd.special(7) May 09 13:27:22 testvm1 systemd: Reached target Graphical Interface. [root@testvm1 ~]# systemctl status default.target ● graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled) Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago Docs: man:systemd.special(7) May 09 13:27:22 testvm1 systemd: Reached target Graphical Interface.
The default target is the graphical target. The status of any unit can be checked in this way.
Mounts the old way
A mount unit defines all of the parameters required to mount a filesystem on a designated mount point. systemd can manage mount units with more flexibility than those using the /etc/fstab filesystem configuration file. Despite this, systemd still uses the /etc/fstab file for filesystem configuration and mounting purposes. systemd uses the systemd-fstab-generator tool to create transient mount units from the data in the fstab file.
I will create a new filesystem and a systemd mount unit to mount it. If you have some available disk space on your test system, you can do it along with me.
Note that the volume group and logical volume names may be different on your test system. Be sure to use the names that are pertinent to your system.
You will need to create a partition or logical volume, then make an EXT4 filesystem on it. Add a label to the filesystem, TestFS, and create a directory for a mount point /TestFS.
To try this on your own, first, verify that you have free space on the volume group. Here is what that looks like on my VM where I have some space available on the volume group to create a new logical volume:
[root@testvm1 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 120G 0 disk ├─sda1 8:1 0 4G 0 part /boot └─sda2 8:2 0 116G 0 part ├─VG01-root 253:0 0 5G 0 lvm / ├─VG01-swap 253:1 0 8G 0 lvm [SWAP] ├─VG01-usr 253:2 0 30G 0 lvm /usr ├─VG01-home 253:3 0 20G 0 lvm /home ├─VG01-var 253:4 0 20G 0 lvm /var └─VG01-tmp 253:5 0 10G 0 lvm /tmp sr0 11:0 1 1024M 0 rom [root@testvm1 ~]# vgs VG #PV #LV #SN Attr VSize VFree VG01 1 6 0 wz--n- <116.00g <23.00g
Then create a new volume on VG01 named TestFS. It does not need to be large; 1GB is fine. Then create a filesystem, add the filesystem label, and create the mount point:
[root@testvm1 ~]# lvcreate -L 1G -n TestFS VG01 Logical volume "TestFS" created. [root@testvm1 ~]# mkfs -t ext4 /dev/mapper/VG01-TestFS mke2fs 1.45.3 (14-Jul-2019) Creating filesystem with 262144 4k blocks and 65536 inodes Filesystem UUID: 8718fba9-419f-4915-ab2d-8edf811b5d23 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done [root@testvm1 ~]# e2label /dev/mapper/VG01-TestFS TestFS [root@testvm1 ~]# mkdir /TestFS
Now, mount the new filesystem:
[root@testvm1 ~]# mount /TestFS/ mount: /TestFS/: can't find in /etc/fstab.
This will not work because you do not have an entry in /etc/fstab. You can mount the new filesystem even without the entry in /etc/fstab using both the device name (as it appears in /dev) and the mount point. Mounting in this manner is simpler than it used to be—it used to require the filesystem type as an argument. The mount command is now smart enough to detect the filesystem type and mount it accordingly.
Try it again:
[root@testvm1 ~]# mount /dev/mapper/VG01-TestFS /TestFS/ [root@testvm1 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 120G 0 disk ├─sda1 8:1 0 4G 0 part /boot └─sda2 8:2 0 116G 0 part ├─VG01-root 253:0 0 5G 0 lvm / ├─VG01-swap 253:1 0 8G 0 lvm [SWAP] ├─VG01-usr 253:2 0 30G 0 lvm /usr ├─VG01-home 253:3 0 20G 0 lvm /home ├─VG01-var 253:4 0 20G 0 lvm /var ├─VG01-tmp 253:5 0 10G 0 lvm /tmp └─VG01-TestFS 253:6 0 1G 0 lvm /TestFS sr0 11:0 1 1024M 0 rom [root@testvm1 ~]#
Now the new filesystem is mounted in the proper location. List the mount unit files:
[root@testvm1 ~]# systemctl list-unit-files -t mount
This command does not show a file for the /TestFS filesystem because no file exists for it. The command systemctl status TestFS.mount does not display any information about the new filesystem either. You can try it using wildcards with the systemctl status command:
[root@testvm1 ~]# systemctl status *mount ● usr.mount - /usr Loaded: loaded (/etc/fstab; generated) Active: active (mounted) Where: /usr What: /dev/mapper/VG01-usr Docs: man:fstab(5) man:systemd-fstab-generator(8) <SNIP> ● TestFS.mount - /TestFS Loaded: loaded (/proc/self/mountinfo) Active: active (mounted) since Fri 2020-04-17 16:02:26 EDT; 1min 18s ago Where: /TestFS What: /dev/mapper/VG01-TestFS ● run-user-0.mount - /run/user/0 Loaded: loaded (/proc/self/mountinfo) Active: active (mounted) since Thu 2020-04-16 08:52:29 EDT; 1 day 5h ago Where: /run/user/0 What: tmpfs ● var.mount - /var Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Thu 2020-04-16 12:51:34 EDT; 1 day 1h ago Where: /var What: /dev/mapper/VG01-var Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 (limit: 19166) Memory: 212.0K CPU: 5ms CGroup: /system.slice/var.mount
This command provides some very interesting information about your system's mounts, and your new filesystem shows up. The /var and /usr filesystems are identified as being generated from /etc/fstab, while your new filesystem simply shows that it is loaded and provides the location of the info file in the /proc/self/mountinfo file.
Next, automate this mount. First, do it the old-fashioned way by adding an entry in /etc/fstab. Later, I'll show you how to do it the new way, which will teach you about creating units and integrating them into the startup sequence.
Unmount /TestFS and add the following line to the /etc/fstab file:
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2
Now, mount the filesystem with the simpler mount command and list the mount units again:
[root@testvm1 ~]# mount /TestFS [root@testvm1 ~]# systemctl status *mount <SNIP> ● TestFS.mount - /TestFS Loaded: loaded (/proc/self/mountinfo) Active: active (mounted) since Fri 2020-04-17 16:26:44 EDT; 1min 14s ago Where: /TestFS What: /dev/mapper/VG01-TestFS <SNIP>
This did not change the information for this mount because the filesystem was manually mounted. Reboot and run the command again, and this time specify TestFS.mount rather than using the wildcard. The results for this mount are now consistent with it being mounted at startup:
[root@testvm1 ~]# systemctl status TestFS.mount ● TestFS.mount - /TestFS Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Fri 2020-04-17 16:30:21 EDT; 1min 38s ago Where: /TestFS What: /dev/mapper/VG01-TestFS Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 (limit: 19166) Memory: 72.0K CPU: 6ms CGroup: /system.slice/TestFS.mount Apr 17 16:30:21 testvm1 systemd: Mounting /TestFS... Apr 17 16:30:21 testvm1 systemd: Mounted /TestFS.
Creating a mount unit
Mount units may be configured either with the traditional /etc/fstab file or with systemd units. Fedora uses the fstab file as it is created during the installation. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab file. Now that you know you can use systemd .mount unit files for filesystem mounting, try it out by creating a mount unit for this filesystem.
First, unmount /TestFS. Edit the /etc/fstab file and delete or comment out the TestFS line. Now, create a new file with the name TestFS.mount in the /etc/systemd/system directory. Edit it to contain the configuration data below. The unit file name and the name of the mount point must be identical, or the mount will fail:
# This mount unit is for the TestFS filesystem # By David Both # Licensed under GPL V2 # This file should be located in the /etc/systemd/system directory [Unit] Description=TestFS Mount [Mount] What=/dev/mapper/VG01-TestFS Where=/TestFS Type=ext4 Options=defaults [Install] WantedBy=multi-user.target
The Description line in the [Unit] section is for us humans, and it provides the name that's shown when you list mount units with systemctl -t mount. The data in the [Mount] section of this file contains essentially the same data that would be found in the fstab file.
Now enable the mount unit:
[root@testvm1 etc]# systemctl enable TestFS.mount Created symlink /etc/systemd/system/multi-user.target.wants/TestFS.mount → /etc/systemd/system/TestFS.mount.
This creates the symlink in the /etc/systemd/system directory, which will cause this mount unit to be mounted on all subsequent boots. The filesystem has not yet been mounted, so you must "start" it:
[root@testvm1 ~]# systemctl start TestFS.mount
Verify that the filesystem has been mounted:
[root@testvm1 ~]# systemctl status TestFS.mount ● TestFS.mount - TestFS Mount Loaded: loaded (/etc/systemd/system/TestFS.mount; enabled; vendor preset: disabled) Active: active (mounted) since Sat 2020-04-18 09:59:53 EDT; 14s ago Where: /TestFS What: /dev/mapper/VG01-TestFS Tasks: 0 (limit: 19166) Memory: 76.0K CPU: 3ms CGroup: /system.slice/TestFS.mount Apr 18 09:59:53 testvm1 systemd: Mounting TestFS Mount... Apr 18 09:59:53 testvm1 systemd: Mounted TestFS Mount.
This experiment has been specifically about creating a unit file for a mount, but it can be applied to other types of unit files as well. The details will be different, but the concepts are the same. Yes, I know it is still easier to add a line to the /etc/fstab file than it is to create a mount unit. But this is a good example of how to create a unit file because systemd does not have generators for every type of unit.
This article looked at systemd units in more detail and how to use the systemctl command to explore and manage units. It also showed how to stop and disable units and create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
In the next article in this series, I will take you through a recent problem I had during startup and show you how I circumvented it using systemd.
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI