Am 30.03.2015 um 04:56 schrieb Michael Biebl: > Looks like a found a simple reproducer (this is on my work laptop) done > during normal runtime of the system: > > $ rm /etc/udev/rules.d/70-persistent-net.rules > $ while true ; do echo add > /sys/class/net/eth0/uevent ; done > > I let this run for one or two seconds and had over 100 entries in > 70-persistent-net.rules. > udevd went totally nuts and consumed almost 100% CPU, but a simple > systemctl restart systemd-udevd.service fixed that. > > > So, while I don't have a solution yet, at least I have now a simple way > to reproduce it reliably. Therefor marking the bug accordingly.
I think I have a pretty good explanation now, why this happens and why the lock_rules_file() function does not really prevent this: Say we have multiple add events. NAME is not yet set for the interface. So we we call write_net_rules for all of them and they spin in lock_rules_file() and when they get their turn, they pick the next free name i.e. increase the counter. The problem happens if you have multiple add events *before* the rules file is written and NAME is not yet set. Those multiple add events could be the result of "something" calling udevadm trigger multiple times for example, as you rightfully pointed out Faidon. Talked to Marco via IRC and this seemed plausible to him. He also mentioned, that he might have a simple fix for it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
