From: Martin Wilck <mwilck@suse.com>
To: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: LVM general discussion and development
<linux-lvm@e1890.dsca.akamaiedge.net>,
Christian Hesse <list@eworm.de>,
Heming Zhao <heming.zhao@suse.com>,
Oleksandr Natalenko <oleksandr@natalenko.name>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd
Date: Fri, 19 Feb 2021 10:22:15 +0100 [thread overview]
Message-ID: <d23747147bb305d5067f6958cdb776f1307e403b.camel@suse.com> (raw)
In-Reply-To: <20210218153009.z66cp4j7ptukk4zs@butterfly.localdomain>
On Thu, 2021-02-18 at 16:30 +0100, Oleksandr Natalenko wrote:
> >
> > 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.
>
Good point. That allows us to conclude that pvscan may hang on exit
when udevd isn't available at the time (has been already stopped). That
positively looks like an lvm problem. The After= is a viable
workaround, nothing more and nothing less. We'd need to run pvscan with
increased debug/log level to figure out why it doesn't stop. Given that
you have a workaround, I'm not sure if it's worth the effort for you.
What strikes me more in your logs is the fact that systemd proceeds
with switching root even though the pvscan@253:2 service hasn't
terminated yet. That looks a bit fishy, really. systemd should have
KILLed pvscan before proceeding.
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/
next prev parent reply other threads:[~2021-02-22 8:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 11:16 [linux-lvm] [PATCH 1/1] pvscan: wait for udevd 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 [this message]
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
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=d23747147bb305d5067f6958cdb776f1307e403b.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@natalenko.name \
--cc=oleksandr@redhat.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).