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
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
Re: [systemd-devel] firmware update check script
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
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
[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
Re: [systemd-devel] machined: after CPU offline then online, vcpupin KVM guest failed to start
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] Reacting to non-systemd mounts
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
Re: [systemd-devel] Reacting to non-systemd mounts
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
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
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