[systemd-devel] Is there a way to override the "Where" option in mount units?

[Dennis Jacobfeuerborn]

On 31.10.2017 11:33, Jérémy Rosen wrote:
> you could mask the original unit and symlink it with a new name in /etc
> 
> you could probably use Alias= in the [Install] section to have that
> automated at install time... not sure if that would work, some testing
> is needed.
> 
> On 31/10/2017 11:19, Dennis Jacobfeuerborn wrote:
>> Hi,
>> I'm trying to set up a redundant nfs server but the problem I'm
>> currently running into is that I need to move the
>> /var/lib/nfs/rpc_pipefs mountpoint outside of /var/lib/nfs.
>> The original mountpoint is handled by
>> /usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount which comes as part
>> of the nfs-utils RPM.
>> So my initial naive idea was to create a drop-in in /etc/systemd/system
>> and override the "Where" option but that's when I learned that this
>> option cannot differ from the mount unit filename.
>>
>> This creates a dilemma for me since I shouldn't modify the original
>> mount unit both in principle and because it would mess up things
>> horribly when updating. Due to the limitations on the mount unit
>> filename I cannot create a drop-in directory either though so I'm not
>> sure what the appropriate way to handle this situation is.
>>
>> The only way I can think of is to disable/mask the original mount unit
>> and create a completely new one or is there another way to deal with
>> this?

One problem that complicates this is that various NFS services require
this mount unit which means a) masking that unit will break the startup
of these services and b) using an alternative unit file would result in
it no longer getting mounted automatically.

The alias thing is worth a try though so I need to experiment what
happens when I mask unit X and then create a new unit Y that has X as an
alias to see if the alias or the masking take precedence.

I really wish that one could specify an abstract unit name instead of
this specific naming requirement as that essentially leads to some
implicit dependencies not based on units but actual path names.

Regards,
  Dennis