What is systemd ?
systemd is a suite of software that provides fundamental building blocks for a Linux operating system. It is an initialization system and hence the first process to start (with pid 1). It will start and manage other services and manage dependencies between them.
It replaced sysvinit, upstart in many Linux distributions. As of now almost all popular Linux distributions use systemd as the default init system (including my favorite Debian).
All this while to mount a volume after boot automatically, we used to mess around with fstab. Recently I came to know we can use systemd to mount volumes and here is how to do it.
Unit configuration file
Configuration for any entity (service,socket,device,mount point etc) that is managed by systemd is maintained in unit configuration files. They are usually located in /etc/systemd/system.
You can use systemctl command to start/stop/restart check status of services in your machine.
systemctl status postgresql.service
systemctl start postgresql.service
systemctl stop postgresql.service
systemctl restart postgresql.service
This command offers much more functionality please refer the manpage for more details.
# systemctl status postgresql.service
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2018-05-20 17:37:20 IST; 1 day 20h ago
Process: 976 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 976 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/postgresql.service
Mount unit Configuration
To mount a filesystem using systemd we create special type of unit files which have an extension of .mount and .automount
Mount units must be named after the mount point directories they control. Example: the mount point /home/lennart must be configured in a unit file home-lennart.mount.
[Unit]
Description=Additional drive
[Mount]
What=/dev/disk/by-uuid/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Where=/mnt/driveone
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
Then you can enable this unit using :
systemctl enable mnt-driveone.mount
Automount
These unit file configurations ends with .automount. This can be used to automatically mount the filesystem on demand.
Description=Automount Additional Drive
[Automount]
Where=/mnt/driveone
[Install]
WantedBy=multi-user.target
Automount units must be named after the automount directories they control.
Every automount unit file must have a matching mount unit configuration, which is activated when the path (Where) in automount configuration is accessed.
so the unit configuration required to mount /mnt/mydata is :
/etc/systemd/system/mnt-mydata.automount
/etc/systemd/system/mnt-mydata.mount
Originally posted in JigsawCode
Top comments (5)
Worth noting that systemd-based distributions like Red Hat 7 already uses systemd for mount management. The fstab acts as a source-file that provides backwards-compatibility to non systemd-aware SAs (and, more importantly, CM tools). That
fstabfile is actually processed at boot time and converted into systemd units. The resultant unit files are stored in/run/systemd/generator/<MOUNT-PATH>.mount. If you do asystemctl -t mount, you'll see that there's a 1:1 relationship between the contents offstaband mount-units. Further, if you query one of those units (e.g.,systemctl status -- -.mount), one of the things you'll see in the resulting output is a reference tosystemd-fstab-generator.Couple things to bear in mind when you consider walking the path of doing all mounts as "native" unit files, though:
Thanks for bringing these up, currently at work all machines are systemd based and we use chef as CM tool. We use chef templates to create these mount unit files. It was a little easy to add one file (unit configuration) than fiddle with fstab from chef.
As a dev I didn’t knew about feature of mounting volumes with systemd, so wanted to share it.
Yeah. It's kind of cool ...just know that I ended up with a complaint-storm at my desk when I started offering up systems that had empty
fstabs. =)Dunno if you've had occasion to deal with layered-mounts (e.g.,
/opt/oracle,/opt/oracle/data,/opt/oracle/logs), or not. With systemd being a parallelized system (part of why systemd-enabled systems boot faster that upstart-enabled or older init-type systems), you typically want to take extra care with your unit-files. Specifically, you'll want to make sure that your layered mounts' unit-files use appropriate dependency-directives —Requiresand/orBefore/Afterdirectives. Absent their use, you can end up in a situation where a lower-level mount happens after a higher-level mount (e.g.,/opt/oracle/datamounts before/opt/oraclecreating a situation where/opt/oracleeffectively hides the content of/opt/oracle/data)Wouldn't systemd provide an implicit dependencies in this case ?
Sort of. Bot only in as much as you get from alphabetical ordering. E.g., if you have the layered-mounts
/var(var.mount),/var/log(var-log.mount), and/var/log/auditvar-log-audit.mountsystemd should initiate them a few msec apart and — in that order — simply because of the service-directory's scan-order. That said, you open yourself to unexpected results and race-conditions by not over-specifying the dependencies. Which is to say, 99.999% of the time, things will work as expected, but there can be times where they don't and then you'll be pulling your hair out wondering why. ;)