Bug 551928

Summary:	sys-fs/udev-220 - Race condition will prevent "udevadm trigger ..."
Product:	Gentoo Linux	Reporter:	Thomas Deutschmann (RETIRED) <whissi>
Component:	[OLD] Core system	Assignee:	Gentoo systemd Team <systemd>
Status:	RESOLVED TEST-REQUEST
Severity:	major	CC:	bathtor, krinpaus, polynomial-c
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://bugs.gentoo.org/show_bug.cgi?id=551644
Whiteboard:
Package list:		Runtime testing required:	---

Description Thomas Deutschmann (RETIRED) gentoo-dev

2015-06-13 00:55:33 UTC

Hi,

like said in bug 551644 comment #30 I have the problem that sometimes my NICs won't be renamed on boot. The problem first appeared with the recent changes to sys-fs/udev-init-script but that's not the root cause:

I have a udev rule which will rename my NICs:

$ cat /etc/udev/rules.d/80-net-setup-link.rules
# Internal network
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:e4:XX:XX:XX", NAME="internal0"

# External network
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:e4:ZZ:ZZ:ZZ", NAME="external0"


This was working fine with sys-fs/udev-220-r1 and sys-fs/udev-init-scripts-27.

With the new udev-init-scripts-29, sometimes my NICs aren't renamed on boot. Like written in bug 551644 comment #32 a "sleep 10" before calling "udevadm trigger --type=devices --action=add" helps but this only uncovers a race condition.

So I bisected udev and found the bad commit (http://cgit.freedesktop.org/systemd/systemd/commit/?id=aeb24f3081ad4971a82d90a9dac4cbe8da3bb228):

  commit aeb24f3081ad4971a82d90a9dac4cbe8da3bb228
  Author: Lennart Poettering <lennart@poettering.net>
  Date:   Thu May 14 11:30:14 2015 +0200
  
      util: use GNU comparison function prototype for qsort_safe()


It wasn't easy to find because it is a race condition but I am very sure that's the bad commit:

I build udev with the previous commit (7185d80558f7d85ddb67da0268a0f47138bf1401) and rebooted about 30 times without any problems (my NICs were always renamed).

With the bad commit I rebooted 10 times and 3 times my NICs weren't renamed...

Reproducible: Always

Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev

2015-06-13 13:33:50 UTC

Well, seems like that aeb24f3081 was not the bad commit:

I did the bisect on a physical system (FUJITSU PRIMERGY RX200 S8). In the meantime I have rebooted this system about 130 times with udev build from commit 7185d80558f7d85ddb67da0268a0f47138bf1401 (this is the previous commit before the "bad" commit) and it works. I never experienced a problem with 7185d805 to date.

Rebooting the system with udev build from aeb24f3081ad4971a82d90a9dac4cbe8da3bb228 however fails sometimes (not on every boot, but sometimes).

I tried to build sys-fs/udev-220-r1 with "git show -R aeb24f3081" applied but still saw failures. So yes, it is very unlikely that this is the bad commit. 


However I tried another physical system (HP DL120 Gen9). This system failed to boot 10 of 10 times with udev build from aeb24f3081ad4971a82d90a9dac4cbe8da3bb228 _and_ 7185d80558f7d85ddb67da0268a0f47138bf1401. So I started a new bisect using this system. New bad commit:

  commit ecb17862ad969cc15e94f95d0255b51ba3e588e1
  Author: Tom Gundersen <teg@jklm.no>
  Date:   Tue May 12 19:06:33 2015 +0200
  
      udevd: manager - move a few global variables into the Manager object


But I am unable to just undo this patch (too many changes; functions like event_queue_update were removed later...).

But at least this commit looks more promising, not?

Any idea how to proceed?

Comment 2 Klemen Mihevc 2015-06-13 14:39:29 UTC

Same issues with renaming NICs... didnt do multiple boots to check if at least sometimes they get renamed properly, but reverted init scripts from ~28/29 to ~27 and issue is gone. So this issue started for me with udev-init-scripts-28. So atm i just masked it.

Comment 3 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev

2019-04-20 18:13:33 UTC

Still an issue with recent udev releases?