Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd

2021-02-26 Thread Oleksandr Natalenko
On 22 February 2021 14:04:17 CET, Christian Hesse  wrote:
>Zdenek Kabelac  on Mon, 2021/02/22 10:57:
>> > I've gone through the various tasks that dmeventd is responsible
>for,
>> > and I couldn't see anything that'd be strictly necessary during
>early
>> > boot. I may be overlooking something of course. Couldn't the
>monitoring  
>> 
>> As said - during ramdisk boot - monitor shall not be used (AFAIK -
>dracut
>> is supposed to use disabled monitoring in it's modified copy of
>lvm.conf
>> within ramdisk)
>
>I could not find anything in dracut that modifies lvm.conf, but looks
>like
>dracut calls the lvm commands with `--ignoremonitoring`.
>
>To date this is not handled in lvm2's mkinitcpio hook... Wondering if
>that would help. Oleksandr, you could undo the udev workaround, then
>apply
>the following diff to /usr/lib/initcpio/install/lvm2, regenerate the
>initramfs and retry?
>
>--- lvm2_install   (revision 408582)
>+++ lvm2_install   (working copy)
>@@ -34,6 +34,7 @@
> add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
>add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules"
>"/usr/lib/udev/rules.d/11-dm-initramfs.rules"
> add_file "/etc/lvm/lvm.conf"
>+sed -i '/^\smonitoring =/s/1/0/' "${BUILDROOT}/etc/lvm/lvm.conf"
> 
> # this udev rule is specific for systemd and non-systemd systems
> if command -v add_systemd_unit >/dev/null; then

Hi.

This changes nothing, sorry. The issue is still there.
-- 
  Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer


___
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd

2021-02-19 Thread Oleksandr Natalenko
Hi.

(will comment only on what I can comment, dropping the rest)

On Thu, Feb 18, 2021 at 04:19:01PM +0100, Martin Wilck wrote:
> > I'm not sure this issue is reproducible with any kind of LVM layout.
> > What I have is thin-LVM-on-LUKS-on-LVM:
> 
> I saw MD in your other logs...?

FWIW, one of the machines have soft RAID, another does not, the issue
is reproducible regardless of whether there's soft RAID or not.

> > Feb 10 17:24:26 archlinux lvm[643]:   pvscan[643] VG sys run
> > autoactivation.
> > Feb 10 17:24:26 archlinux lvm[643]:   /usr/bin/dmeventd: stat failed:
> > No such file or directory
> 
> What's going on here? pvscan trying to start dmeventd ? Why ? There's a
> dedicated service for starting dmeventd (lvm2-monitor.service). I can
> see that running dmeventd makes sense as you have thin pools, but I'm
> at a loss why it has to be started at that early stage during boot
> already.
> 
> This is a curious message, it looks as if pvscan was running from an
> environment (initramfs??) where dmeventd wasn't available. The message
> is repeated, and after that, pvscan appears to hang...

Not sure either. FWIW, real root is on a thin volume (everything is,
in fact, except /boot and swap).

> > Feb 10 17:24:26 archlinux lvm[720]:   pvscan[720] PV /dev/md0 online.
> > Feb 10 17:24:26 archlinux lvm[643]:   /usr/bin/dmeventd: stat failed:
> > No such file or directory
> > Feb 10 17:24:26 archlinux lvm[643]:   WARNING: Failed to monitor
> > sys/pool.
> > Feb 10 17:24:56 spock systemd[1]: lvm2-pvscan@253:2.service: State
> > 'stop-sigterm' timed out. Killing.
> > Feb 10 17:24:56 spock systemd[1]: lvm2-pvscan@253:2.service: Killing
> > process 643 (lvm) with signal SIGKILL.
> > Feb 10 17:24:56 spock systemd[1]: lvm2-pvscan@253:2.service: Main
> > process exited, code=killed, status=9/KILL
> > Feb 10 17:24:56 spock systemd[1]: lvm2-pvscan@253:2.service: Failed
> > with result 'timeout'.
> > Feb 10 17:24:56 spock systemd[1]: Stopped LVM event activation on
> > device 253:2.
> 
> So what's timing out here is the attempt to _stop_ pvscan. That's
> curious. It looks like a problem in pvscan to me, not having reacted to
> a TERM signal for 30s.
> 
> It's also worth noting that the parallel pvscan process for device 9:0
> terminated correctly (didn't hang).

Yes, pvscan seems to not react to SIGTERM. I have
DefaultTimeoutStopSec=30s, if I set this to 90s, pvscan hangs for 90s
respectively.

-- 
  Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer

___
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd

2021-02-18 Thread Oleksandr Natalenko
Hello.

On Wed, Feb 17, 2021 at 02:49:00PM +0100, Martin Wilck wrote:
> On Wed, 2021-02-17 at 13:03 +0100, Christian Hesse wrote:
> > 
> > Let's keep this in mind. Now let's have a look at udevd startup: It
> > signals
> > being ready by calling sd_notifyf(), but it loads rules and applies
> > permissions before doing so [0].
> > Even before we have some code about handling events and monitoring
> > stuff.
> 
> It loads the rules, but events will only be processed after entering
> sd_event_loop(), which happens after the sd_notify() call.
> 
> Anyway, booting the system with "udev.log-priority=debug" might provide
> further insight. Oleksandr, could you try that (without the After=
> directive)?

Yes.

pvscan: http://ix.io/2PLK
udev: http://ix.io/2PLL
lvm: http://ix.io/2PLM

Let me know if I can collect something else.

Thanks.

-- 
  Oleksandr Natalenko (post-factum)

___
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd

2021-02-17 Thread Oleksandr Natalenko
: sys-devices-virtual-block-dm\x2d2.device: 
Failed to enqueue SYSTEMD_WANTS= job, ignoring: Transaction for 
lvm2-pvscan@253:2.service/start is destructive (lvm2-pvscan@253:2.service has 
'stop' job queued, but 'start' is included in transaction).
```

I'm not sure I understand what it means, though. Likely, this is just
because of first pvscan invocation being stuck.

If needed, I can intentionally break one of the machines again, but to
do that please let me know what kind of data I should collect. I'm not
sure plain journal will reveal more, maybe, I should apply some extra
debug options?

Thanks.

-- 
  Oleksandr Natalenko (post-factum)


___
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/