Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
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 fstab file 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 a systemctl -t mount, you'll see that there's a 1:1 relationship between the contents of fstab and 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 to systemd-fstab-generator.
Couple things to bear in mind when you consider walking the path of doing all mounts as "native" unit files, though:
If you share management responsibilities for a system (e.g., once something leaves dev and goes to prod), doing a full conversion is likely to cause considerable heartache. This will be especially so for people that aren't systemd specialists (like, say, security accreditors whose tools aren't adequately systemd-aware and will red-flag your system-config before you can move it to prod) and in environments that either aren't 100% Linux or has Linux distros that aren't systemd-based.
If you want to "cheat" and save yourself some heavy-lifting, dump your new, soon to be natively-managed mount into fstab and let the generator process it into a base unit file. Then, copy the resultant file to its permanent location, edit it to suit, and, finally, nuke the fstab shim-entry
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.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
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 — Requires and/or Before/After directives. 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/data mounts before /opt/oracle creating a situation where /opt/oracle effectively hides the content of /opt/oracle/data)
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
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.mount systemd 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. ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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. ;)