Re: [systemd-devel] Reacting to non-systemd mounts
Hi, On 05/08/2016 09:26, Andrei Borzenkov wrote: > In this case pragmatic solution is to order your service after mmfsd > startup, assuming your filesystems are configured to be automounted I already have such a dep in place, but due to the asynchronous nature of GPFS the mount can (and does) happen seconds or even tens of seconds after mmfsd is up and running. It's... "complicated" :-) > 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. I'm already using device units to have gpfs.service wait for its LUs to be ready and it works flawlessly. Having a way to declare a passive dep on a mount unit would simplify the "downward" flow and avoid ugly kludges with mountinfo or GPFS callbacks. But even if it gets implemented I'd have to wait for a downstream backport, so I still have to write "something" in the meantime :-) Regards, -- Matteo Panella INFN CNAF Via Ranzani 13/2 c - 40127 Bologna, Italy Phone: +39 051 609 2903 smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reacting to non-systemd mounts
Hi, On 04/08/2016 22:03, Lennart Poettering wrote: > How does GPFS suggest that apps wait for the mounts? It "grew" official support for systemd only in very recent releases, so up until now most people just threw a busy wait in rc.?d between S*gpfs and other services[1]. > 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. Or a tool which waits for a notification from a GPFS mount callback (which would use an officially-sanctioned interface of GPFS). I wished to avoid writing custom code, but it seems there is no way around this. Thanks anyway :-) [1]: while GPFS provides a callback mechanism for some events (incl. mounts), its use for synchronously starting services is not advised as it might interfere with mmfsd operations. Regards, -- Matteo Panella INFN CNAF Via Ranzani 13/2 c - 40127 Bologna, Italy Phone: +39 051 609 2903 smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reacting to non-systemd mounts
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. 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 smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reacting to non-systemd mounts
Hi, sorry for bothering you with a fairly uncommon issue, but I haven't been able to find a solution so far and Google turned up empty. I have some CentOS 7.2 machines with systemd 219 which are members of an IBM GPFS cluster and need to start up some services only after a specific GPFS filesystem is mounted. Long story short, I can't simply add a Wants= dependency on the relevant mount unit because systemd would try to mount the filesystem and only GPFS itself should use mount.gpfs. Aside from busy-looping in a Type=oneshot unit while waiting for the mount to appear[1], is there any way to have systemd react to a mount unit becoming active as a result of a "manual" mount? [1]: for those well-versed in GPFS, I ruled out a GPFS callback because slapping a "systemctl start" in it because during boot it would be fired while the transition to default.target is still taking place :-) Thanks, -- Matteo Panella INFN CNAF Via Ranzani 13/2 c - 40127 Bologna, Italy Phone: +39 051 609 2903 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
