[Bug 1669564] Re: udevadm trigger subsystem-match=net doesn't always run rules
Ryan Harper
1669564 at bugs.launchpad.net
Tue May 2 14:32:32 UTC 2017
On Tue, May 2, 2017 at 8:54 AM, Dimitri John Ledkov <launchpad at surgut.co.uk>
wrote:
> Ideally, the following should happen:
> * boot
> * Created link configuration context
> <netplan creates/changes .link files to have a new MTU setting>
> * Check if link configuration needs reloading -> appears in the debug logs
> * New MTU is successfully applied
>
Let me put in the cloud-init sequence and see if we can figure out what may
be missing.
* boot
* systemd-udev* sockets, trigger, settle, udevd , cloud-init-local : run
* cloud-init writes a netplan.yaml
* cloud-init invokes netplan-generate
* system reaches sysinit.target
Looking at the deps on the systemd-udev units; there's no strict ordering
in cloud-init
that says it would run before, or strictly after udev related units.
If you note about the ignoring updated files that are less than 3 seconds
old as well
as systemd's variability w.r.t unit ordering due to missing explicit
Before/After directives
might explain the race.
I'd prefer not to wait for 3 seconds just because; so it maybe use useful
to see if we can
run cloud-init before udev; however it's not clear if invoking udev settle
in cloudinit (which
is done at various places directly (or indirectly through calling programs
like blkid or other
system programs) would end up waiting.
We could also explicitly order cloud-init-local after the udevd service
which depends on
all other udev units; however, if cloud-init runs immediately after it,
the 3 seconds may not
have passed.
I like running after udevd, but I would like to see if we can
force/configure udev to not
wait that 3 seconds;
> If the 'Check ...' is missing from the debug logs, after netplan has
> run, udevd will not reload the configs.
>
> I also would have thought that calling udevadm control --reload would
> force it to reload the contexts for the builtins.
>
> >From the original bug report description there is a call to:
> 'systemctl', 'start', '--no-block', 'systemd-udev-trigger.service'
>
> But if one is doing that, to avoid races, one should call udevadm settle
> -t 3 before re-triggering add.
>
Note that -t 3, --timeout=3 only sets the maxium wait time; this means
that if it
processes any event with in those 3 seconds, that we may not have waited
long
enough for udev when it re-reads link files and says it's not 3 seconds
since the last
time.
The 3 second re-read is arbitrary and ideally should be replaced by content
hashing or
use of inotify such that changes to the file (.link) can be triggered
automatically without
hacky things like sleep 3.
> These things are possibly red herrings too.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1669564
>
> Title:
> udevadm trigger subsystem-match=net doesn't always run rules
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/
> 1669564/+subscriptions
>
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1669564
Title:
udevadm trigger subsystem-match=net doesn't always run rules
Status in systemd package in Ubuntu:
New
Bug description:
1. root at ubuntu:~# lsb_release -rd
Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
2. root at ubuntu:~# apt-cache policy udev
udev:
Installed: 232-18ubuntu1
Candidate: 232-18ubuntu1
Version table:
*** 232-18ubuntu1 500
500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages
100 /var/lib/dpkg/status
3. udevadm trigger --verbose --subsystem-match=net --action=add will run and read .link files from /run/systemd/network/10-netplan-interface1.link
and apply MTU settings
4. during system boot running (3) does not set the MTU; running (3)
after boot has completed MTU is set correctly.
Here'a log during boot where cloud-init generates a netplan config,
invokes `netplan generate` which writes the networkd config out
and then udevadm trigger (3). Upon logging in interface1 has an MTU of 1500. Re-running udevadm trigger now runs the rules/link files and updates the MTU.
Note that, if you run udevadm test /sys/class/net/interface1; this also will
apply the MTU (test probably shouldn't change the interface, I'll file a
bug for that as well).
# journalctl -o short-precise --no-pager -b | grep WARK
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['netplan', '--debug', 'generate']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['stat', '/run/systemd/network/10-netplan-interface1.link']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['cat', '/run/systemd/network/10-netplan-interface1.link']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['systemctl', 'start', '--no-block', 'systemd-udev-trigger.service']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['udevadm', 'trigger', '--verbose', '--subsystem-match=net', '--action=add']:
root at ubuntu:~# cat /run/systemd/network/10-netplan-interface1.link
[Match]
MACAddress=52:54:00:12:34:02
[Link]
Name=interface1
WakeOnLan=off
MTUBytes=1492
root at ubuntu:~# ifconfig interface1
interface1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.100 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::5054:ff:fe12:3402 prefixlen 64 scopeid 0x20<link>
inet6 fec0::5054:ff:fe12:3402 prefixlen 64 scopeid 0x40<site>
ether 52:54:00:12:34:02 txqueuelen 1000 (Ethernet)
RX packets 16 bytes 5053 (5.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35 bytes 3287 (3.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root at ubuntu:~# udevadm trigger --verbose --subsystem-match=net --action=add
/sys/devices/pci0000:00/0000:00:04.0/virtio1/net/interface1
/sys/devices/pci0000:00/0000:00:05.0/virtio2/net/interface2
ys/devices/pci0000:00/0000:00:06.0/virtio3/net/interface0
/sys/devices/virtual/net/lo
root at ubuntu:~# ifconfig interface1
interface1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 10.0.2.100 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::5054:ff:fe12:3402 prefixlen 64 scopeid 0x20<link>
inet6 fec0::5054:ff:fe12:3402 prefixlen 64 scopeid 0x40<site>
ether 52:54:00:12:34:02 txqueuelen 1000 (Ethernet)
RX packets 16 bytes 5053 (5.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 37 bytes 3504 (3.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: udev 232-18ubuntu1
ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8
Uname: Linux 4.10.0-8-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
Date: Thu Mar 2 19:22:14 2017
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcEnviron:
TERM=vt220
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic root=UUID=8bbb84fe-91e8-4a9a-bd91-f6af4793727e ro console=ttyS0
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.10.1-1ubuntu1
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-i440fx-zesty
dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.1-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-zesty:cvnQEMU:ct1:cvrpc-i440fx-zesty:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-zesty
dmi.sys.vendor: QEMU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+subscriptions
More information about the foundations-bugs
mailing list