Running a script after network is up

Hi, I am struggling with this. I need to run a simple script that adds static routes. For this I need network to be up. I followed instructions for systemd, script is executed, but too soon. If I put sleep 40 into it, all is fine.

Description=Configure routes for VPN networking.service connman.service networking.service connman.service



I tried several different services in after and required section, but if i do ifconfig in script, I have only loopback. Any idea which service should I wait for ? I am connected via wifi with DHCP.

1 Like

There isn’t a good place to do this just at the moment. You need /etc/ifup.d/ support so that a script can run after the interface comes up, however although we have just added the ifupdown package it doesn’t appear to be working together with connman properly.

This is being investigated.

Any progress?

I’ve the same problem - run a script after a network interface comes up - so far this thread is the nearest I’ve seen to a solution.

Go into the Networking module of MyOSMC, ensure that Wait for Network is set as ON and then on boot OSMC will wait for a network connection before continuing.

Any script after that should be able to rely on the network being available. Trade-off is that you always have to have a network available.

This won’t work for adding static routes @Karnage

@cagney: no there has been no further progress made on this.

This is not a bug fix but rather writing entirely new functionality into connman that doesn’t currently exist and unfortunately there are quite a few higher priority tasks ahead of it. But it is still on our todo list.

When it is done I am sure it will be mentioned in the release notes of an update.

Does the functionality even need to be in connman? Seems to me that installing ifplugd is the way to go. Though I confess I haven’t tried it yet, but plan to today.

I just skimmed the description page for ifplugd but I doubt that it will work with connman:

“Uses your distribution’s native ifup/ifdown programs”

Connman does not have or use any ifup/ifdown scripts, so I can’t see how this would work. And if it tried to configure the network directly at a kernel interface level then it would conflict with connman.

cc @sam_nazarko

Well, the scripts would be provided by _me (_actually already were in my Pi’s previous incarnation). In my particular case, I was using iproute2 to add IP addresses to an interface. I don’t see why that has to conflict with connman. I think it should work for the OPs case, too.

Anyway, I’ll try it tonight and report back.

Why wouldn’t they conflict ?

Connman is the network manager, it’s its job to bring up interfaces, configure their IP addresses, add routes and configure resolv.conf. If you are also trying to assign IP addresses and add routes using your own scripts you have a race condition between connman and your scripts.

Just because it might seem to work doesn’t mean it will be reliable. If you’re trying to configure the interfaces yourself you would have to mask the connman service.

This will not work. ifplugd is a minor connection manager in its own right. The user would need to -I eth0 in ConnMan’s invocation like we do for NFS.

Well, I beg to differ. As Sam says, ifplugd is a minor connection manager. It waits for events on the interface, and triggers actions.

# cat /etc/network/interfaces
auto eth0
iface eth0 inet static
        post-up /media/NAS/repository/bin/secondary-ifs

I probably don’t need most of that – connmand is doing it

# connmanctl monitor
Service      ethernet_b827eb8e2496_cable IPv4 = [ Method=fixed, Address=, Netmask=, Gateway= ]

So, connman is paying no attention to my secondary address, but the secondary address is set:

$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:8e:24:96 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever
    inet scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe8e:2496/64 scope link 
       valid_lft forever preferred_lft forever

A simplification. I don’t need /etc/network/interfaces at all.

  • Install ifplugd,
  • put the script you need to execute into /etc/ifplugd/action.d/


I misunderstood your question. I thought that you wanted hotplug events to work (i.e. network going up and down), but it seems this is not the case, and that you just want to add a secondary IP address on boot. Because ifup.d is being invoked for loopback, you are getting lucky and it is working on boot. It’s invoked for lo because it’s handled by systemd, not ConnMan.

But if you synthesise a hotplug event or remove/reinsert the cable, you will see it’s not always honoured. The only way to guarantee if(up|down).d runs for eth0, is to configure it via systemd or /etc/network/interfaces and blacklist it in our start-network script. Otherwise, the script is being triggered for lo, and just because eth is up, the 2nd IP is being added. This is racy and is not going to work if the network connection drops.

If you only want addresses set when you boot (the only time lo is brought up) then you could just do this with /etc/rc.local with ip addr add on boot, no extra package needed. Sounds like that is what you are after.

Not quite right, I just wanted secondary addresses, but they can only be assigned on network connection. The OP wanted to change routes, but it should work for that too.

It doesn’t even use ifup.d now, since I moved my script to /etc/ifplugd/action.d, and it is being honoured every time I connect the ethernet. I didn’t look too closely: aiui, all the scripts in action.d are getting executed on every removal and reinsertion, and I’m not checking the arguments my script gets called with, so I’m sure it’s doing unnecessary work on removal. I also suspect that since my ip add commands seem to trigger another event in connmand, that it gets called recursively, but on any subsequent attempt to set an existing IP address it’ll throw RTNETLINK File Exists, so it’s not an infinite recursion.

It doesn’t work to do this on network start (lo). You have to already have an IP address on eth0 to add new addresses to eth0. I spent ages trying to find a way to do this with systemd on my old system, but in the end I had to use ifupdown. This method is still hacky, but cleaner than what I was doing then!