8 thoughts on - Systemd Service Unit File Needs To Wait Until A Specific Interface Is Up

• So the network just calls the scripts and exits so they can take a while to get working. I think this website covers what you want to do

  https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service

  systemctl list-units –no-pager | grep subsystem-net

  Then look for the device which matches the one you are listening to. Change the After=network.target to

  BindsTo=sys-devices-virtual-net-.device After=sys-devices-virtual-net-.device

  where is the interface you found (aka eth2, br9, bond0 etc)

  —
  Stephen J Smoogen.

• Perfect!! Many thanks Stephen. Works like a charm.

   > Hi all,
  >
  >
  > With SystemD, how can I make certain service dependent on certain network
  > interfaces being up?
  >
  > For example, I have an 802.1ad bond interface I need to wait on for being
  > up (this interface has no ip address assigned, it is used to capture
  > networks packets with a tcpdump’s script). Every time this service fails
  > because bond interface is not up.
  >
  >
  >
  > I have configured the service as:
  >
  >
  > [Unit]
  >
  > Description=tcpdump capture script
  >
  > After=network.target
  >
  > Wants=network-online.target
  >
  >
  >
  > But it doesn’t work …. Any tip or trick?
  >
  >
  >

  So the network just calls the scripts and exits so they can take a while to
  get working. I think this website covers what you want to do

  https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service

  systemctl list-units –no-pager | grep subsystem-net

  Then look for the device which matches the one you are listening to. Change
  the After=network.target to

  BindsTo=sys-devices-virtual-net-.device
  After=sys-devices-virtual-net-.device

  where is the interface you found (aka eth2, br9, bond0 etc)

  > My host is CentOS8 x86_64.
  >
  >
  > Regards,
  > C. L. Martinez
  >
  >

• Hmm, there seems to be several layers here.

  I think sys-devices-.device is “started” when appears in the kernel:

  Sep 23 19:37:25 kernel: virtio_net virtio0 ens3: renamed from eth0

  # systemctl status sys-subsystem-net-devices-ens3.device
  ● sys-subsystem-net-devices-ens3.device – Virtio network device
  Loaded: loaded
  Active: active (plugged) since Wed 2020-09-23 19:37:25 MDT

  This is not what most people would consider “up” – i.e. have an IP
  address. ens3 doesn’t get it’s IP address until much later.

  This works for Carlos though because he doesn’t need an IP address –
  just the device existing.

  I have no idea how it worked for the stackexchange poster. Apparently because “lan0” is a virtual device as well
  (“sys-devices-virtual-net-lan0”) that they need, not a more “physical”
  device like “net-devices-ens3”, and it gets an IP address at the same time as creation.

  I’ve been dealing with issues like this for a while – systems with multiple interfaces, some of which do not come up for quite a while, and I need to wait for all to be up before running certain tasks. Still haven’t found anything very satisfactory.

  —
  Orion Poplawski Manager of NWRA Technical Systems 720-772-5637
  NWRA, Boulder/CoRA Office FAX: 303-415-9702
  3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/

• Oh good point. I didn’t think about that.

  It may or may not.. I just realized that the device may need to get recognized by a switch etc which on a bond may take time.

  All good points. Thank you for that douse of reality.

  —
  Stephen J Smoogen.

• I’m just wondering, is there a chance to make this work reliable without modifying the source code of systemd?

  Simon

• Polling? If “some of [them] do not come up for quite a while” it would not be a problem to add another couple of seconds, I guess.

  It might be against an “event driven” aproach, but it would work and you can add all sorts of tests to make sure everything is ready for your job
  (eg. including reachability of remote services, etc.)

  Peter

• Sounds like a job for shell scripts then – or how do you integrate it with systemd?

  I still have a lot of such stuff waiting here for being ported to the new systemd world and I still don’t really know how to do it best.

  For pretty standard things it’s easy to use systemd unit files but as soon as it gets more complicated, bash scripting feels much easier to me than systemd unit scripting :-(

  Simon

• Exactly: Write a service that is just a script waiting for all the things to come up and to be ready. Then do the real thing. I guess you could use that script as a target to reach and you could then wait for
  *that* in other services.