4

I wish to express the following sequence of commands in terms of Systemd mount units and systemctl invocations:

# mount /some/path /some/mountpoint -o ro
# mount /some/mountpoint -o remount,rw
# touch /some/mountpoint/foo # placeholder for write action
# mount /some/mountpoint -o remount,ro

The conceptual problem appears to be that systemd.mount(5) operates on mountpoints. Since units are activated by passing the full path into systemctl, one cannot have multiple mount units for the same mountpoint. Templates don’t work for mount units either.

So how does it work? Is it possible at all?

2

Use a service unit instead of a mount unit

A simple oneshot service unit with the mount command worked for my remount use case (and I assume it'll work for yours).

Given that the mounts are often already defined in /etc/fstab and systemd automatically generated a <mountpoint>.mount for fstab entries, there are two approaches:

  1. Simply fallback to a standard service unit instead of a mount unit and directly control the mount command.
  2. Try use a systemd override? (Not tested, don’t think it’s viable)
    • Mount units have a strict requirement that the unit be named according to the mountpoint, so it’s probably not possible to run two separate mount units for the same mountpoint (already noted in the question).
    • Hence, this probably won't work for remounts, assuming it only overrides the original mount unit definition generated from fstab, and won’t execute twice.
    • If attempted, it’s more likely the original mount will probably fail given the remount option applied to something not yet mounted.

Example

I needed something similar and bumped into the following issue with trying to use the systemd mount unit type (because I didn't define my unit filename according to the mountpoint):

Where= setting doesn't match unit name. Refusing.

Given a bind mount to a data dir with more space, but with the parent mountpoint having nosuid and nodev set, I needed to add suid and dev privileges for lxc at /var/lib/lxc.

The service unit file /etc/systemd/system/lxc-remount.service:

[Unit]
Description=Remount the /var/lib/lxc folder with suid and dev privileges
Requires=var-lib-lxc.mount
After=var-lib-lxc.mount
Before=lxc.service

[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,rw,suid,dev,relatime,discard,data=ordered /var/lib/lxc

[Install]
WantedBy=lxc.service

Commands to put it into effect:

$ sudo systemctl daemon-reload
$ sudo systemctl enable lxc-remount.service
Created symlink from /etc/systemd/system/lxc.service.wants/lxc-remount.service to /etc/systemd/system/lxc-remount.service.
$ sudo systemctl start lxc-remount.service
1
  • 1
    The advantage of systemd.mount(5) is that it figures out dependencies between mount points for you. Falling back on a service unit kind of defeats the purpose.
    – phg
    Dec 13 '16 at 8:11
1

It is technically possible to implement this on top of systemd mount units. Therefore I cannot simply answer "no". There are a couple of disadvantages of this approach.

On the other hand, you can meet every requirement except for "use systemd mount units", by doing the remount part using the mount command. Note that systemd is generally quite happy for people to use the mount command. For example, if you temporarily unmount a filesystem with umount, the systemd mount unit will be marked as inactive. And when you use mount to mount a filesystem manually, systemd creates a transient mount unit for it. (Note it does not create a unit file).

Therefore in practice I would recommend using the mount command to perform the remount operations.

If you are reading this question and you have an additional reason not to use the mount command, please ask a new question with the specific reason. Without knowing any such reason, I cannot recommend actually using the method below. It is presented for educational purposes only.


You need to alter the Options= setting of the mount unit, and then systemctl reload the mount unit.

You can do this using a drop-in file which has this option only, underneath /run/systemd/system/. So you don't have to edit the on-disk configuration. If the system crashes part-way through, there is no risk of leaving a stale configuration.

It's not very "clean", however. It still risks that your commands are interrupted part-way through, and you could leave a stale configuration in two places - the state of the mount in the kernel, and the state of the mount in systemd. The first problem would exist anyway when using mount. But it means you could fix the first problem and forget about the second problem. Then the second problem could possibly cause a lot of confusion later on.

Note that when you create a drop-in file or edit the unit file, you will also have to run systemctl daemon-reload to pick up the new Option= value, before you reload the mount unit.

This is the second problem - I wouldn't really recommend to use this, at least for now. systemctl daemon-reload is a somewhat heavyweight operation :-). It could also have unwanted side-effects if you are unlucky. Some code was added at some point, to work towards reloading an individual unit file, but I don't see that documented as a usable feature yet.

(I also noticed one of the special unit directories /run/systemd/system.control/ is described as "transient configuration created using the dbus API". I believe this is used to keep track of changes to resource control settings and a few others. I think these are special cases, which can be changed using systemctl --runtime set-property. I assume they do not require a full reload).

11
  • Not sure if I understand you correctly. Are you suggesting to modify the mount unit before each invocation? That would defeat the notion of a static configuration.
    – phg
    Nov 16 '18 at 9:55
  • @phg systemd does not inherently require a static configuration. The resource control configuration can be temporarily modified at run time. access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… . As can everything else, by using /run/systemd/system, but AFAIK the resource control settings are the only ones that don't require a horribly heavyweight reload at the moment.
    – sourcejedi
    Nov 16 '18 at 10:26
  • @phg "drop-in" files e.g. in /run allow you to override one specific option, without specifiying everything else again.
    – sourcejedi
    Nov 16 '18 at 10:30
  • @phg it's not clear why you want to do your temporary remount using systemd? You can use mount to temporarily remount, systemd will not complain at all, all that will happen is that if you systemctl reload the mount unit, it will reset the options back again.
    – sourcejedi
    Nov 16 '18 at 10:32
  • “it's not clear why you want to do your temporary remount using systemd” – Set different mount options, as stated in the question. E. g. ro most of the time and rw when actually needed.
    – phg
    Nov 16 '18 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.