Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Lorenz]

Hi Michael, Axel

I had a system crash yesterday, during an upgrade. Udev, Grub and mdadm
were
all involved in the upgrade. The system went down during the postinst
stage, leaving
some packages uncofigured.
Even if i can't reproduce running

udevadm control --reload-rules

I think it's the same problem.
Also, i had 2 similar crashes during an upgrade in October and December
2018. Looking at
apt logs i found that both udev and grub were involved in those upgrades.
I can reproduce the crash with the following

# dpkg -i -i udev_240-4_amd64.deb mdadm_4.1-1_amd64.deb
also this works as well (in crashing my system)
#dpkg -i udev_240-4_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb
while the both the following don't lead to a crash
# dpkg -i mdadm_4.1-1_amd64.deb grub-pc_2.02+dfsg1-10_amd64.deb
# dpkg -i udev_240-4_amd64.deb && dpkg -i grub-pc_2.02+dfsg1-10_amd64.deb


>Is this specific to version 240-2?
>Could you try downgrading udev to either 239-15 or 240-1 and report back
>with the results.

Downgraded udev down to udev-239-7, wich looks safe to me while udev 239-8
is affected; i'm currently with  239-8.

>Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
>only process which survives this issue and hence might be involved.

i don't have sysvinit-core installed, init is runit.

>So I wonder what part of my setup causes this:
>
>* 2x LVM on LUKS on MD RAID1 (2 spinning HDDs and 2 SSDs)
>* an (internal) USB 3.0 SD card reader which lets LVM throw warnings
>  about "no medium found" for all devices from /dev/sde to /dev/sdk or so.
>* Three screens (1x HDMI, 1x DP, 1x DVI-D)
>* Logitech USB dongle with Solaar

I have
* runit as PID 1
* /home is on  RAID mirror
* mdadm is installed
* systemd is not installed
* kernel is 4.18.0-1-amd64

>I can't reproduce this problem.
>Neither with a 4.18 (4.18.20-2), 4.19 (4.19.12-1) or 4.20 (4.20-1~exp1)
>kernel. Tested both with systemd as PID 1 and inside a VM with sysvinit
>as PID 1.

That's not my enough, i suspect you need also one (or more than one) of
the following:
* no systemd installed
* mdadm installed
* a RAID setup (althought i'm not sure this one is feasible in virtualbox)

Anything else i can do to help solving this?
Thanks,
Lorenz






Il giorno mer 16 gen 2019 alle ore 15:49 Dmitry Bogatov <KAction at debian.org>
ha scritto:

>
> [ More eyes is better, so please use sysvinit at packages.debian.org
>   instead personally me for sysvinit-related issues. I read list
>   carefully. ]
>
> [2019-01-15 16:17] Axel Beckert <abe at debian.org>
> > Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
> > only process which survives this issue and hence might be involved.
> > (Dmitry: Please tell me if I should rather send this to the
> > mailing-list.)
> >
> > I will probably also check if an earlier sysvinit version, like e.g.
> > 2.88dsf-59.11 (as 2.88dsf-60 IIRC had some issues of its own), makes
> > the issue go away, just to be sure (like with udev 239-15).
>
> Yes, please compare with sysvinit-core=2.88dsf-59.9 (version from
> stable), but I doubt it have something to do with sysvinit, since the
> only way sysvinit interacts with udev is 'Should-Start: udev'
> dependency of some bin:initscripts.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190118/402a1509/attachment.html>