CentOS - Sep 2020 - Systemd service unit file needs to wait until a specific interface is up

> On Wed, 23 Sep 2020 at 23:39, Orion Poplawski <orion at nwra.com>
wrote:
>
>> On 9/23/20 7:07 AM, Stephen John Smoogen wrote:
>> > On Wed, 23 Sep 2020 at 04:33, Carlos Lopez <clopmz at
outlook.com> wrote:
>> >
>> >> 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>.device
>> > After=sys-devices-virtual-net-<device>.device
>> >
>> > where <device> is the interface you found (aka eth2, br9,
bond0 etc)
>>
>> Hmm, there seems to be several layers here.
>>
>> I think sys-devices-<device>.device is "started" when
<device> 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.
>>
>>
>
> Oh good point. I didn't think about that.
>
>
>> This works for Carlos though because he doesn't need an IP address
-
>> just the device existing.
>>
>>
> 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.
>
>
>> 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.
>>
>>
> All good points. Thank you for that douse of reality.
I'm just wondering, is there a chance to make this work reliable without
modifying the source code of systemd?

Simon

On 24/09/2020 13:41, Simon Matter wrote:
>>
>>> 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.
>>>
>>>
>> All good points. Thank you for that douse of reality.
> 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

> On 24/09/2020 13:41, Simon Matter wrote:
>>>
>>>> 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.
>>>>
>>>>
>>> All good points. Thank you for that douse of reality.
>> 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.)
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