[systemd-devel] Reacting to non-systemd mounts

Lennart Poettering lennart at poettering.net
Thu Aug 4 20:03:10 UTC 2016


On Thu, 04.08.16 22:00, Matteo Panella (matteo.panella at cnaf.infn.it) wrote:

> 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
> 
> Everything happens asynchronously and systemd notices that the
> filesystem has been mounted only through mountinfo.
> 
> > 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.

How does GPFS suggest that apps wait for the mounts?

You could probably write a small tool that watches
/proc/self/mountinfo (the fd of it generates POLLPRI on each mount
change, so you wouldn't even have to do a time-based loop), turn that
into a service and order it before your service.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list