You could use the networkd-broker tool (or its predecessor networkd-dispatcher) to react to networkd's configuration events, or a netlink-based tool (similar to `ip mon addr`) to directly watch IP address changes.
To be honest though, a bond0 that's connected to two completely different networks kind of makes no sense to me at all. How is it better than just having two network interfaces? On Thu, Sep 29, 2022 at 12:22 PM m1027 <m1...@posteo.net> wrote: > Hi, > > With a working wlan/lan bond0 failover, how can we trigger other > local services whenever a failover happens? > > Why: In our case, a local openvpn client service needs SIGUSR1 > whenever the own IP address changes, after a failover. See man > openvpn(8), --ipchange. > > The problem: After a failover, the openvpn client keeps sitting on > the wrong IP address/interface. Sending SIGUSR1 manually helps > indeed: openvpn then reconfigures itself and uses the correct IP > address. The man page recommends to write a hook script for the > local dhcpcd to send SIGUSR1 to the openvpn client, however we are > not using dhcpcd but systemd. > > Some more information: > > - Failover works in general here; pulling out the cable from lan1 > activates wlan0 and vice versa, and this triggers external DHCP > servers to issue a new IP address. The external servers are > triggered because of FailOverMACPolicy=active for bond0. > > - Our bond0 is on top of wlan0 + lan1 and configured like this: > > [NetDev] > Name=bond0 > Kind=bond > [Bond] > Mode=active-backup > AdSelect=bandwidth > FailOverMACPolicy=active > > - We know of networkmanager's dispatcher scripts but are looking for > a solution within systemd. (It's also unclear whether our network > setup could be configured entirely by networkmanager.) > > - There is a workaround: There is the "inactive <sec>" option for > the openvpn client to shutdown in case of no action. And we can > additionally set the client to Restart=always. However, this > interrupts even working openvpn client sessions every 60 sec of > inactivity. > > Thanks for any pointers... > > -- Mantas Mikulėnas
