linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: David Teigland <teigland@redhat.com>
Cc: Natalenko <oleksandr@redhat.com>,
	linux-lvm@e1890.dsca.akamaiedge.net,
	Christian Hesse <list@eworm.de>,
	Oleksandr, linux-lvm@redhat.com,
	Heming Zhao <heming.zhao@suse.com>
Subject: Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd
Date: Sun, 21 Feb 2021 21:26:57 +0100	[thread overview]
Message-ID: <0619b194d69a90fcfadb4572c42402d3204f5f0e.camel@suse.com> (raw)
In-Reply-To: <20210219163722.GA13644@redhat.com>

On Fri, 2021-02-19 at 10:37 -0600, David Teigland wrote:
> On Thu, Feb 18, 2021 at 04:19:01PM +0100, Martin Wilck wrote:
> > > 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...
> 
> I've found that when pvscan activates a VG, there's a bit of code
> that
> attempts to monitor any LVs that are already active in the VG. 
> Monitoring
> means interacting with dmeventd.  I don't know why it's doing that,
> it
> seems strange, but the logic around monitoring in lvm seems ad hoc
> and in
> need of serious reworking.  In this case I'm guessing there's already
> an
> LV active in "sys", perhaps from direct activation in initrd, and
> when
> pvscan activates that VG it attempts to monitor the already active
> LV.
> 
> Another missing piece in lvm monitoring is that we don't have a way
> to
> start lvm2-monitor/dmeventd at the right time (I'm not sure anyone
> even
> knows when the right time is), so we get random behavior depending on
> if
> it's running or not at a given point.  In this case, it looks like it
> happens to not be running yet.  I sometimes suggest disabling lvm2-
> monitor
> and starting it manually once the system is up, to avoid having it
> interfere during startup.

That sounds familiar.

> 
> > > 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:26 archlinux systemd[1]: Stopping LVM event
> > > activation
> > > on device 9:0...
> 
> The unwanted failed monitoring seems to have caused the pvscan
> command to
> exit with an error, which then leads to further mess and confusion
> where
> systemd then thinks it should stop or kill the pvscan service,
> whatever
> that means.

The way I read Oleksandr's logs, systemd is killing all processes
because it wants to switch root, not because of errors in the pvscan
service. The weird thing is that that fails for one of the pvscan tasks
(253:2), and that that service continues to "run" (rather, "hang") long
after the root switch has happened.

Thanks,
Martin



_______________________________________________
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/


  parent reply	other threads:[~2021-02-22  8:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 11:16 Christian Hesse
     [not found] ` <f18dff7a-050a-d41d-c643-4616522ba4a0@suse.com>
2021-02-17  8:22   ` Martin Wilck
     [not found]     ` <20210217130329.7de41147@leda>
2021-02-17 13:38       ` Oleksandr Natalenko
2021-02-18 15:19         ` Martin Wilck
2021-02-18 15:30           ` Oleksandr Natalenko
2021-02-19  9:22             ` Martin Wilck
2021-02-19 16:37           ` David Teigland
2021-02-19 22:47             ` Zdenek Kabelac
2021-02-21 20:23               ` Martin Wilck
2021-02-22  9:57                 ` Zdenek Kabelac
2021-02-22 13:04                   ` Christian Hesse
2021-02-25 16:51                     ` Oleksandr Natalenko
2021-02-21 20:26             ` Martin Wilck [this message]
2021-02-17 13:49       ` Martin Wilck
2021-02-17 19:11         ` Oleksandr Natalenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0619b194d69a90fcfadb4572c42402d3204f5f0e.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=heming.zhao@suse.com \
    --cc=linux-lvm@e1890.dsca.akamaiedge.net \
    --cc=linux-lvm@redhat.com \
    --cc=list@eworm.de \
    --cc=oleksandr@redhat.com \
    --cc=teigland@redhat.com \
    --subject='Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).