[systemd-devel] Reacting to non-systemd mounts

[Andrei Borzenkov]

Отправлено с iPhone

> 4 авг. 2016 г., в 23:00, Matteo Panella <matteo.panella at cnaf.infn.it> написал(а):
> 
> Hi,
> 
>> On 04/08/2016 16:43, Mantas Mikulėnas wrote:
>> Then add an After= instead. Unit ordering is already specified 
>> separately from dependencies.
> 
> That does not work, unfortunately: since the entry in fstab is marked
> "noauto" systemd ignores the mount and fires up the service once the
> other dependencies are satisfied.
> 
> To provide a bit of context, GPFS mounts are handled internally by its
> main daemon (mmfsd) and a filesystem may be mounted in the following
> conditions:
> * by mmfsd itself upon startup if the filesystem is registered as
> automatically mounted across the cluster
> * a local mmmount invocation
> * a _remote_ mmmount invocation from a cluster node authorized to
> perform management operations
> 

In this case pragmatic solution is to order your service after mmfsd startup, assuming your filesystems are configured to be automounted

> Everything happens asynchronously and systemd notices that the
> filesystem has been mounted only through mountinfo.
> 

Yes, this is second real life case after ZFS which does not fit in rather simplistic model. We probably need something like passive dependencies similar to how devices are handled, where systemd simply waits for a unit to appear without attempting to start it itself.


>> That said, it's pretty weird that GPFS provides a "mount.gpfs" but 
>> doesn't want anyone to use it. It should just perform the mount
>> directly then, and not provide any /bin/mount helper at all...
> 
> My mistake, in SpectrumScale (formerly GPFS) 4.2 there is no mount.gpfs.
> 
> However that does not solve the underlying issue with a Wants=
> dependency: systemd tries to invoke /bin/mount for the filesystem, mount
> in turn fails with rc=32 because there is no mount.gpfs helper and
> systemd marks the mount unit as failed - that is, until mmfsd mounts the
> filesystem, at which point the dependent units have already been started.
> 
> Right now, I don't see a way around this behaviour that doesn't involve
> a busy wait.
> 
> Regards,
> -- 
> Matteo Panella
> INFN CNAF
> Via Ranzani 13/2 c - 40127 Bologna, Italy
> Phone: +39 051 609 2903
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel