Re: [systemd-devel] Reacting to non-systemd mounts

2016-08-05 Thread Lennart Poettering 
On Fri, 05.08.16 10:26, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> > 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.

Well, I'd really turn this around, and propose that those systems
provide some /bin/mount. tool that makes sure they can be used
using the usual mount/umount logic. In today's world mounting and
unmounting is highly dynamic, and often requires more than trivial
dependencies. Hence I am pretty sure systemd should be able to
schedule mounts correctly, so that it can pull in what is
necessary. There's a nice plug-in interface available to cover this,
it's nicely supported even beyond systemd, and those systems really
should just use that.

ZFS in particular is really broked right now since it assumes that
there was a point in time during boot where all block devices have
shown up. With today's hardware that point in time does not exist
(think hotpluggable disks, such as USB, iSCSI, NBD, …).

So, instead of adjusting systemd to be able to deal with these file
systems, I am pretty sure it should be those file systems that get
fixed to work like hardware (and Linux) work these days, and just
follow the normal plug-in schemes for file systems that need extra
userspace code that is implemented in util-linux.

Lennart

-- 
Lennart Poettering, Red Hat
___
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

2016-08-05 Thread Matteo Panella 
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

2016-08-05 Thread Andrei Borzenkov 


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

> 4 авг. 2016 г., в 23:00, Matteo Panella  
> написал(а):
> 
> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
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

2016-08-04 Thread Matteo Panella 
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

2016-08-04 Thread Matteo Panella 
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

Re: [systemd-devel] Reacting to non-systemd mounts

2016-08-04 Thread Lennart Poettering 
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

Re: [systemd-devel] Reacting to non-systemd mounts

2016-08-04 Thread Lennart Poettering 
On Thu, 04.08.16 16:34, Matteo Panella (matteo.pane...@cnaf.infn.it) wrote:

> 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.

That is strange. /bin/mount.gpfs is a plug-in for /bin/mount, so that
it can mount file systems of that type correctly. It's a way how to
make sure that /bin/mount works on that fs too. If only GPFS is
supposed to call that tool, then it really shouldn't exist in the
first place.

> 
> 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?

Well, what precisely mounts this? If that's some service, consider
just ordering your service of choice after it. (under the assumption
that the service reports to systemd when it finished what it needs to
do to set up the mounts).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel