Re: [systemd-devel] Networkd fails to activate the device on boot
Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). [2.211121] lije systemd[1]: Starting Network Service... [2.230579] lije systemd-networkd[356]: timestamp of '/etc/systemd/network' changed [2.231454] lije systemd-networkd[356]: qemu: Creating tuntap netdev: tap [2.232121] lije systemd-networkd[356]: qemu: loaded tap [2.234423] lije systemd-networkd[356]: qemu: link 3 added [2.234527] lije systemd-networkd[356]: qemu: udev initialized link [2.234630] lije systemd-networkd[356]: qemu: netdev has index 3 [2.234720] lije systemd-networkd[356]: qemu: flags change: +MULTICAST +BROADCAST [2.236465] lije systemd-networkd[356]: qemu: udev initialized link [2.236562] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.236703] lije systemd-networkd[356]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a [2.236852] lije systemd-networkd[356]: qemu: link state is up-to-date [2.237117] lije systemd-networkd[356]: qemu: found matching network '/etc/systemd/network/01-qemu.network' [2.237673] lije systemd-networkd[356]: qemu: enslaved [2.23] lije systemd-networkd[356]: qemu: bringing link up [2.237876] lije systemd-networkd[356]: qemu: setting addresses [2.237972] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.238057] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238155] lije systemd[1]: Started Network Service. [2.238263] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238608] lije systemd-networkd[356]: qemu: flags change: +UP +RUNNING [2.238702] lije systemd-networkd[356]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.2 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a [2.238810] lije systemd-networkd[356]: Got message type=signal sender=org.freedesktop.DBus destination=:1.2 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a [2.238906] lije systemd-networkd[356]: qemu: added address: 10.23.42.129/26 [2.238993] lije systemd-networkd[356]: qemu: addresses set [2.239328] lije systemd-networkd[356]: qemu: link configured [2.239430] lije systemd-networkd[356]: qemu: MAC address: 1a:de:ad:be:ef:01 [2.241023] lije systemd-networkd[356]: qemu: flags change: +LOWER_UP [2.241121] lije systemd-networkd[356]: qemu: gained carrier [3.316936] lije systemd-networkd[356]: qemu: added address: fe80::18de:adff:febe:ef01/64 (There is a service in the background that changes the MAC address of the qemu interface, that's why it changes). As you can see, there is no indication of either enp3s0 or lo. Now, if I bring enp3s0 up manually (ip link set dev enp3s0 up), this happens: [ 68.472579] lije systemd-networkd[356]: enp3s0 : link 2 added [ 68.472864] lije systemd-networkd[356]: enp3s0 : udev initialized link [ 68.473060] lije systemd-networkd[356]: enp3s0 : flags change: +UP +MULTICAST +BROADCAST [ 68.473242] lije systemd-networkd[356]: enp3s0 : link state is up-to-date [ 68.473429] lije systemd-networkd[356]: enp3s0 : found matching network '/etc/systemd/network/01-lan.network' [ 68.473578] lije systemd-networkd[356]: enp3s0 : enslaved [ 68.473718] lije systemd-networkd[356]: enp3s0 : setting addresses [ 68.473854] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [ 68.473988] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474137] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474275] lije systemd-networkd[356]: enp3s0 : added address: 10.23.42.4/26 [ 68.474424] lije systemd-networkd[356]: enp3s0 : addresses set [ 68.474565] lije systemd-networkd[356]: enp3s0 : setting routes [ 68.474975] lije systemd-networkd[356]: enp3s0 : routes set [ 68.475132] lije systemd-networkd[356]: enp3s0 : link configured [ 70.054677] lije systemd-networkd[356]: enp3s0 :
Re: [systemd-devel] Networkd fails to activate the device on boot
On Sat, Aug 16, 2014 at 6:53 PM, Thomas Bächler tho...@archlinux.org wrote: Hello Tom, I am using systemd 215-4 from Arch Linux. I have the following configuration files in /etc/systemd/network: # 01-lan.network [Match] Name=enp3s0 [Network] Address=10.23.42.4/26 Gateway=10.23.42.3 # 01-qemu.netdev [NetDev] MACAddress=1a:de:ad:be:ef:01 Name=qemu Kind=tap # 01-qemu.network [Match] Name=qemu [Network] Address=10.23.42.129/26 I have two problems with this setup: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. Here is an excerpt from the journal: [2.356909] lije systemd[1]: Starting Network Service... [2.377715] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377862] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377960] lije systemd-networkd[367]: qemu: link configured [2.379489] lije systemd[1]: Started Network Service. [ 57.298036] lije systemd[1]: Stopping Network Service... [ 57.298776] lije systemd-networkd[367]: Received SIGTERM from PID 1 (systemd). [ 57.364169] lije systemd[1]: Starting Network Service... [ 57.451984] lije systemd-networkd[490]: lo : gained carrier [ 57.452133] lije systemd[1]: Started Network Service. [ 57.492641] lije systemd-networkd[490]: qemu: link configured [ 57.492732] lije systemd-networkd[490]: enp3s0 : link configured [ 59.074472] lije systemd-networkd[490]: enp3s0 : gained carrier Any ideas? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd fails to activate the device on boot
Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). I don't know if I'll get to it today, but I'll try to do it ASAP. I did not try latest git, and I'd like to avoid it on real hardware if possible. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. I didn't know you can simply fix anything in the kernel. With the general inertia of kernel development, such a fix would take between 4 and 6 months to be available in a mainline release. Personally, I'd opt for the two-step process with ioctl+rtnl, which we could drop as soon as a new rtnl interface has existed for some time. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. That was my first idea (before I even considered using a .netdev unit), since the tap interface was created by vde_switch. Here's the thing: .link units cannot match on names. There is no workaround for this problem with networkd only. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd fails to activate the device on boot
On Mon, Aug 18, 2014 at 7:02 PM, Thomas Bächler tho...@archlinux.org wrote: Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). I don't know if I'll get to it today, but I'll try to do it ASAP. I did not try latest git, and I'd like to avoid it on real hardware if possible. Thanks. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. I didn't know you can simply fix anything in the kernel. Well, people could always backport. But I agree, it is slow work. The patch itself should not be many lines though. With the general inertia of kernel development, such a fix would take between 4 and 6 months to be available in a mainline release. Personally, I'd opt for the two-step process with ioctl+rtnl, which we could drop as soon as a new rtnl interface has existed for some time. I'm hesitant to add the rtnl+ioctl work-around though, it would probably mean that a real fix would never be made, and after all this is just a missing feature rather than a real bug. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. That was my first idea (before I even considered using a .netdev unit), since the tap interface was created by vde_switch. Here's the thing: .link units cannot match on names. There is no workaround for this problem with networkd only. Indeed, you are right, the .link unit will not work. One would have to write a custom udev rule. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Networkd fails to activate the device on boot
Hello Tom, I am using systemd 215-4 from Arch Linux. I have the following configuration files in /etc/systemd/network: # 01-lan.network [Match] Name=enp3s0 [Network] Address=10.23.42.4/26 Gateway=10.23.42.3 # 01-qemu.netdev [NetDev] MACAddress=1a:de:ad:be:ef:01 Name=qemu Kind=tap # 01-qemu.network [Match] Name=qemu [Network] Address=10.23.42.129/26 I have two problems with this setup: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Here is an excerpt from the journal: [2.356909] lije systemd[1]: Starting Network Service... [2.377715] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377862] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377960] lije systemd-networkd[367]: qemu: link configured [2.379489] lije systemd[1]: Started Network Service. [ 57.298036] lije systemd[1]: Stopping Network Service... [ 57.298776] lije systemd-networkd[367]: Received SIGTERM from PID 1 (systemd). [ 57.364169] lije systemd[1]: Starting Network Service... [ 57.451984] lije systemd-networkd[490]: lo : gained carrier [ 57.452133] lije systemd[1]: Started Network Service. [ 57.492641] lije systemd-networkd[490]: qemu: link configured [ 57.492732] lije systemd-networkd[490]: enp3s0 : link configured [ 59.074472] lije systemd-networkd[490]: enp3s0 : gained carrier Any ideas? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
