Hi Leonid!
> I asked because you could try and see if networkd can acquire a lease by
> itself, without dhcpcd (I don't expect it to).
Actually, the reason I am using dhcpcd fro mthe command line is as a debugging
measure, because I originally setup a .network file for this interface to
attempt to allow systemd-networkd to handle acquiring the DHCP lease. In line
with your expectations, this failed, so I tried using dhcpcd to see if I could
glean what was happening. I will happily provide the disabled .network file I
tried using if you would like to review it, but I'm fairly confident it isn't
the issue.
> Also, could you run dhcpcd
> with "-d -t 0" (debug output, no timeout) to see what it's doing?
Always happy to gather more information! See the output below
[root@host01 ~]# ip l show switch0
7: switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
mode DEFAULT group default
link/ether 4e:c1:ff:d9:d1:49 brd ff:ff:ff:ff:ff:ff
[root@host01 ~]# dhcpcd -dd -t0 switch0
dhcpcd[361]: version 6.4.3 starting
dhcpcd[361]: all: IPv6 kernel autoconf disabled
dhcpcd[361]: switch0: IPv6 kernel autoconf disabled
dhcpcd[361]: switch0: adding address fe80::4cc1:ffff:fed9:d149
dhcpcd[361]: if_addaddress6: Operation not supported
dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
dhcpcd[361]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e
dhcpcd[361]: switch0: IAID ff:d9:d1:49
dhcpcd[361]: switch0: delaying DHCP for 0.7 seconds
dhcpcd[361]: switch0: using ClientID 01:4e:c1:ff:d9:d1:49
dhcpcd[361]: switch0: soliciting a DHCP lease
dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 4.5 seconds
dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 7.7 seconds
dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 15.2 seconds
dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 31.5 seconds
> I have seen a similar issue with networkd and bonding of interfaces. It
> turned out that the way networkd works with links is racy, so in ~70% of
> boots dhcp lease attempts failed both via networkd and dhcpcd. The only
> solution which I found was to use netctl (should be availabel on ALARM)
> where you can explicitly specify a precise order in which links should be
> managed.
Yuck. I'm really not a fan of netctl, and would probably sooner hack together
some oneshot service files that manually setup the interfaces and acquire
leases. So it sounds like systemd-networkd is not quite ready for prime time
when it comes to being a complete interface management solution. I guess
that's what I get for living life on the edge ;)
On Thursday 25 September 2014 18:23:47 Leonid Isaev wrote:
> Hi,
>
> On Wed, Sep 24, 2014 at 08:14:55PM -0700, James Lott wrote:
> > Hello,
> >
> > There is no .network file for the bridge. Systemd-networkd is currently
> > only in charge of setting up the interface. As you can see from the
> > provided output in my original email, I am running the dhcpcd service
> > directly from the command line (the output from each run of the dhcpcd
> > service is included in that email as well).
>
> I asked because you could try and see if networkd can acquire a lease by
> itself, without dhcpcd (I don't expect it to). Also, could you run dhcpcd
> with "-d -t 0" (debug output, no timeout) to see what it's doing?
>
> I have seen a similar issue with networkd and bonding of interfaces. It
> turned out that the way networkd works with links is racy, so in ~70% of
> boots dhcp lease attempts failed both via networkd and dhcpcd. The only
> solution which I found was to use netctl (should be availabel on ALARM)
> where you can explicitly specify a precise order in which links should be
> managed.
>
> Cheers,
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
