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

[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

[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

[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

[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

[systemd-devel] Reacting to non-systemd mounts

[Matteo Panella]

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

Re: [systemd-devel] machined: after CPU offline then online, vcpupin KVM guest failed to start

[Cedric Bosdonnat]

Hi Lennart and Werner,

On Wed, 2016-08-03 at 16:56 +0200, Lennart Poettering wrote:
> On Wed, 03.08.16 14:46, Dr. Werner Fink (werner at suse.de) wrote:
> > problem with v228 (and I guess this is also later AFAICS from logs of
> > current git) that repeating CPU hotplug events (offline/online). The
> > root cause is that cpuset.cpus become not restored by machined.
> > Please note that libvirt can not do this as it is not allowed to do
> > so.
> 
> This is a limitation of the kernel cpuset interface, and it's one of
> the reasons we do not expose cpusets at all in systemd right
> now. Thankfully, there's an alternative to cpusets, which is the CPU
> affinity controls exposed via CPUAffinity= in systemd, which do much
> of the same, but have less borked semantics.
> 
> We'd like to support cpusets directly in systemd, but we don't do this
> as long as the kernel interfaces are as borked as they are. For
> example, cpusets are flushed out entirely currently when the system
> goes through a suspend/resume cycle.
> 
> If libvirt has hook-ups with cpuset, then it bypasses systemd for
> that.

I guess by CPU affinity you mean sched_setaffinity and friends. If that is
the case, then this is constrained by cpuset too as mentioned here:

http://www.mjmwired.net/kernel/Documentation/cpusets.txt#53

As long as the machine.slice cpuset isn't restored after onlining a CPU again,
then libvirt won't be able to set either the affinity or the cpuset if it
contains that CPU.

May be the kernel's behaviour is weird and can be discussed, but libvirt can't
do anything on that bug.

--
Cedric
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] firmware update check script

[Stéphane ANCELOT]

Hi,

I am already doing this with other init systems with modern usb , I am able 
doing this with my TV, soundbar...
The only bad thing is that systemd has sprayed in some recent distributions 
(where are the benefits ?)

Unfortunately in today's world, there are more commercial people than 
technician people.

No matter, I will not debate more, I gave and made myself an  opinion regarding 
 systemd.

Regards,
S.Ancelot

- Mail original -
De: "Lennart Poettering" 
À: "Stéphane ANCELOT" 
Cc: systemd-devel@lists.freedesktop.org
Envoyé: Jeudi 4 Août 2016 12:21:27
Objet: Re: [systemd-devel] firmware update check script

On Thu, 04.08.16 09:45, Stéphane ANCELOT (sance...@free.fr) wrote:

> You are right, but that's only  systemd that is incompatible with
> this feature (and some more).

No, that has little to do with systemd. It's a systematic change how
today's hardware works, and that probing is asynchronous and USB the
way USB is.

The only difference with systemd is that we don't pretend that
hardware would work a way it doesn't work.




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] firmware update check script

[Lennart Poettering]

On Thu, 04.08.16 09:45, Stéphane ANCELOT (sance...@free.fr) wrote:

> You are right, but that's only  systemd that is incompatible with
> this feature (and some more).

No, that has little to do with systemd. It's a systematic change how
today's hardware works, and that probing is asynchronous and USB the
way USB is.

The only difference with systemd is that we don't pretend that
hardware would work a way it doesn't work.

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] firmware update check script

[Jóhann B . Guðmundsson]

On 08/04/2016 07:45 AM, Stéphane ANCELOT wrote:


You are right, but that's only  systemd that is incompatible with this feature 
(and some more).


Actually all initsystems are incompatible with this.


As some people and some articles I have read on the web, it is time for myself 
switching my system to a professional initscript service.


If you have not switched your system to an systemd based distribution 
now would be the time.


JBG


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] firmware update check script

[Stéphane ANCELOT]

You are right, but that's only  systemd that is incompatible with this feature 
(and some more).
As some people and some articles I have read on the web, it is time for myself 
switching my system to a professional initscript service.



- Mail original -
De: "Lennart Poettering" 
À: "Stéphane ANCELOT" 
Cc: systemd-devel@lists.freedesktop.org
Envoyé: Mercredi 3 Août 2016 16:47:09
Objet: Re: [systemd-devel] firmware update check script

On Tue, 02.08.16 10:19, Stéphane ANCELOT (sance...@free.fr) wrote:

> Hi,
> 
> It looks like very complicated making easy thing
> 
> I would need only setting up a script that looks for usb media and launch a 
> script if available on it (firmware upgrade)
> 
> unfortunately, it looks like, graphic display is launched in parallel and i 
> am not able doing this in a text only mode, before continuing boot process
> 
> I would need some help to going on.

This cannot work and is incompatible with how modern computers
work. USB devices can take any time they want to initialize, and that
means there's no point in time at boot where all USB sticks are known
to have shown up, since there could always be more still popping up.

You can order your service before the display manager of your choice,
and use Type=oneshot to make sure your tool finishes before the
activation of the DM is attempted, but this will be very racy because
of the aforementioned issue that USB devices can take any time they
like to initialize.

Sorry,

Lennart



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