In systemd, units are files that load things. To tell systemd what it needs to mount, you create mount units. Type find / -name "*.mount" to discover which files already exist for mounting file systems. These are good examples to study, as with the system file /usr/lib/systemd/system/tmp.mount (Listing 1).

# tmp.mount is statically enabled in upstream. In RHEL tmp-on-tmpfs is not used

# by default, but there are cases where it is necessary (anaconda, live images,

# read-only root). Make 'systemctl enable tmp.mount' work:

[Install]

WantedBy=local-fs.target

The structure of a .mount target is relatively easy to understand. The important information is in the [Mount] section of the file: What to mount, where to mount it and which type to use. The file also specifies in which systemd target the unit loads -- comparable to runlevels in the old Linux distributions' file system mounting method. It is nice to include a small description of the unit file as well for future reference. If you're creating mount unit files yourself, you'll have to put the .mount file in the directory /etc/systemd/system.

Listing 2. To practice mounting files, do a test where the logical volume /dev/vgdisk/lvtest is going to be loaded on the directory /test. The contents of the unit file would look like this:

[Unit]

Description = test mount

[Mount]

What = /dev/vgdisk/lvtest

Where = /test

Type = ext4

[Install]

WantedBy = multi-user.target

Mounting file systems with systemd requires the admin to start the unit file and enable it for automatic execution using systemctl start test.mount followed by systemctl enable test.mount. If you restart your computer at this point, the mount will automatically come back because you've told systemd that it should be started in the multi-user.target (this is comparable to runlevel 3). Check if the test file worked by typing mount | grep test and verifying that the logical volume mounted on the /test directory.

Goodbye autofs, hello automount

Systemd controls automounting file systems in new Linux distributions as well. Automounting is the system that mounts a directory automatically as soon as it is accessed, a task previously accomplished by the autofs service.

In systemd, you create a specific file that performs the automount for you. This file needs to reflect the name of the automount directory. So, if the directory /test needs to be automounted, the name of the unit file is going to be test.automount. Each automount unit file needs to have a matching mount unit file. Each automount file contains an [Automount] section with two options: Where and DirectoryMode. "Where" takes the absolute path name of the directory where the file system will automount. "DirectoryMode" specifies the permissions to assign to the automount directory, and defaults to 0755.

Consider the test.mount file example. Assuming that it doesn't have to be mounted all the time, but only if it is accessed, we can disable and stop it. Type systemctl stop test.mount followed by systemctl disable test.mount. Next, create a file with the name /etc/systemd/system/test.automount and give it the following contents:

[Unit]

Description = test automount

[Automount]

Where = /test

[Install]

WantedBy = multi-user.target

Now tell systemd to load this unit and also enable it when restarting, via systemctl start test.automount and systemctl enable test.automountM. Test if it worked by typing mount | grep test before going into the /test directory, and type it again after going into the test directory. But before going into the directory, only systemd-1 should be mounted on /test; after entering the directory your file system will be mounted on it as well, as seen in Listing 3.

If you want to avoid this new way to mount and automount file systems, Linux made systemd backwards compatible with the old method. However, to really get to know your server, take the time to explore systemd and the other changes to your distribution.

1 comment

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy