[arch-general] Problem bringing up bridge interface with netctl

[Leonid Isaev]

On Sun, 29 Sep 2013 17:18:39 -0400
Michael Dahlberg <olgamirth at gmail.com> wrote:

> On Sun, Sep 29, 2013 at 3:44 PM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> 
> > On Sat, 28 Sep 2013 20:59:02 -0400
> > Michael Dahlberg <olgamirth at gmail.com> wrote:
> >
> > > I recently upgraded to systemd-207 and I'm having some problems using
> > > netctl to bring up a bridged interface during the system boot.  The
> > problem
> > > is that systemd will try and bring the bridged interface up before
> > bringing
> > > up the actual network interface that is included in the bridge and, as a
> > > result, it times out:
> > >
> > > (From journalctl)
> > >
> > > Sep 27 23:59:34 io systemd[1]: Job
> > > sys-subsystem-net-devices-net1.710.device/start timed out.
> > > Sep 27 23:59:34 io systemd[1]: Timed out waiting for device
> > > sys-subsystem-net-devices-net1.710.device.
> > > Sep 27 23:59:34 io systemd[1]: Dependency failed for Bridge Connections
> > for
> > > VLAN710 VMs.
> > >
> > >
> > > The netctl bridge profile is
> > >
> > > Description="Bridge Connections for VLAN710 VMs"
> > > Interface=br710
> > > Connection=bridge
> > > BindsToInterfaces=(net1.710)
> > > IP="no"
> > >
> > > The systemd service definition (netctl at br710.service)
> > >
> > > .include /usr/lib/systemd/system/netctl at .service
> > >
> > > [Unit]
> > > Description=Bridge Connections for VLAN710 VMs
> > > BindsTo=sys-subsystem-net-devices-net1.710.device
> > > After=sys-subsystem-net-devices-net1.710.device
> > >
> > > And the profile for net1.710 is
> > >
> > > Description='VLAN 710 VMs'
> > > Interface=net1.710
> > > Connection=vlan
> > > # The variable name is plural, but needs precisely one interface
> > > BindsToInterfaces=net1
> > > VLANID=710
> > > IP=no
> > >
> > >
> > > As soon as systemd times out waiting for the
> > > sys-subsystem-net-devices-net1.710 device to start, it then starts to
> > bring
> > > up the VLAN interface (again from journalctl):
> > >
> > > Sep 27 23:59:35 io network[376]: Starting network profile 'vlan710'...
> > > Sep 27 23:59:37 io kernel: e1000e: net1 NIC Link is Up 100 Mbps Full
> > > Duplex, Flow Control: None
> > > Sep 27 23:59:37 io network[376]: Started network profile 'vlan710'
> > > Sep 27 23:59:37 io systemd[1]: Started VLAN 710 VMs.
> > >
> > >
> > > Obviously, once I have access to the terminal I can manually bring up the
> > > bridge without problems.
> > >
> > > I seem to have an issue with the timing with which the different parts of
> > > the network interfaces are brought up.  Is there a way to force systemd
> > to
> > > bring up the net1.710 device before attempting to start the bridge?
> >
> > Uhh... modify "netctl at br710.service" to require the unit for net1.710,
> > e.g.
> >
> > [Unit]
> > Requires=<unit>
> > After=<unit>
> >
> >
> Hey! Thank you very much; that worked!
> 
> I honestly thought that the lines
> 
> BindsTo=sys-subsystem-net-devices-net1.710.device
> After=sys-subsystem-net-devices-net1.710.device
> 
> which were automatically generated by netctl, would do just that.

No, they instruct systemd to start the unit when those devices appear. This is
an OK strategy when dealing with real (hardware-backed) devices because these
are created by kernel/udev way before systemd gets to netctl units.

However, in your case, the devices are themselves created by netctl, so you
have to order the units somehow. One way is to order individual units, like
you did. Probably a better approach is to create a target "vlan_dev.target"
which is WantedBy netctl at vlan* units, and start all high-level units (netctl
bridges, VMs, LXCs, etc.) after that target...

> 
> Mike

Cheers,
-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130929/a302c2c7/attachment.asc>