Bug#799781: Subject: Re: Bug#799781: device lock race condition between udev and multipathd may cause systemd to abort system boot

Ritesh Raj Sarraf rrs at researchut.com
Mon Sep 28 11:36:09 UTC 2015


On Mon, 2015-09-28 at 01:15 +0300, Tero Marttila wrote:

> > When multipath manages to take a lock on the device,
> > udev will fail, and consequently ignore this entire event.
> > Which in turn might cause the system to malfunction as it
> > might have been a crucial event like 'remove' or 'link down'.
> 
> AFAIK this would be relevant if multipathd is running, and a new SCSI
> device is hotplugged...? Speculation, not testing, on my part.
> 

That's a good point. From what I recollect, multipathd is never started
in the initrd. Yup... Only multipath binary resides in the initrd,
which is responsible only to create the map for the boot LUN (in most
usual cases).

The DAEMON variable in multipath-tools-boot may be misleading, as it
initialized "/sbin/multipath" and not "/sbin/multipathd"

So, during boot, with just /sbin/multipath, if the SCSI device is
acquired by udev, multipath should just plain fail. Where as Niels (OP)
mentioned the issue was seen during early boot.


@Niels: You mentioned that you are stalled on the Single User Mode
prompt. Is that correct ? I'm assuming that at that time, your rootfs
is not mounted ?


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20150928/f399583d/attachment.sig>


More information about the pkg-lvm-maintainers mailing list