On Thu, 04.08.16 22:00, Matteo Panella (matteo.pane...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel