/etc/network/interfaces up, post-up commands not run at network startup

[Peter B]

# lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04

On a multi-homed 14.04 server, the post-up, up, pre-up, etc. scripts are not executed when the network interface is brought up automatically (auto ethN set) at boot.

ifup and ifdown do respect and run these commands if the auto ethN lines are not set in the interfaces config.

/etc/network/interfaces
-----
# The loopback network interface
auto lo
iface lo inet loopback

# Management Net interface
auto eth0
iface eth0 inet static
 address 192.168.50.52
 netmask 255.255.255.0
 up /sbin/ip route add 192.168.50.0/24 dev eth0 src 192.168.50.52 table mgmtroute
 up /sbin/ip route add default via 192.168.50.254 table mgmtroute
 up /sbin/ip rule add from 192.168.50.0/24 table mgmtroute

# Public Net interface
auto eth1
iface eth1 inet static
 address 192.168.60.52
 netmask 255.255.255.0
 gateway 192.168.60.254
 up /sbin/ip route add 192.168.60.0/24 dev eth1 src 192.168.60.52 table hostingroute
 up /sbin/ip route add default via 192.168.60.254 table hostingroute
 up /sbin/ip rule add from 192.168.60.0/24 table hostingroute

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1472055/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Peter B (pbrunnen)]

I *believe* the problem is in the upstart script which should be part of the netscript-2.4-upstart package...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David Garland (davidgarland)]

Is there a workaround so that the routes become active after a system reboot?
My route statements are a little different;

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#Network Interface on DLINK card
auto eth0
iface eth0 inet static
address 192.168.1.91
netmask 255.255.255.0

#Network Interface on motherboard
auto eth1
iface eth1 inet static
address 10.100.1.249
netmask 255.255.255.248
## Persistent routes for the above network back to
## Default Route for Private LAN

post-up route add -net 0.0.0.0/0 gw 192.168.1.254 dev eth0

## Network for A

post-up route add -net 10.101.0.0/20 gw 10.100.1.254 dev eth1
post-up route add -net 10.100.1.0/29 gw 10.100.1.254 dev eth1

## Network for B
post-up route add -net 10.100.1.24/29 gw 10.101.1.254 dev eth1
post-up route add -net 10.114.0.0/21 gw 10.100.1.254 dev eth1

## Network for C
post-up route add -net 10.101.1.16/29 gw 10.100.1.254 dev eth1
post-up route add -net 10.113.0.0/21 gw 10.100.1.254 dev eth1

## Network for D
post-up route add -net 10.112.0.0/20 gw 10.100.1.254 dev eth1

These had been working before, but unfortunately I do not have a time stamp in any previous apt-get install that I can specifically reference when it stopped working.

[Peter B (pbrunnen)]

Hi David,
  I could not reliably make things work for production. I had tried to put ifup/ifdown in my rc.local script and I tried tweaking the upstart scripts... but I couldn't get anything to bring up all the interfaces reliably.

  Noone in the forms bothered to help on this either...

  Upstart is a complete disaster... I ended up abandoning 14.04 altogether, rolled back to a 10.04 snapshot and then forced an upgrade to 12.04 LTS. 12.04 is temperamental at times and also doesn't always bring up the interfaces right, but I can script around it and make sure things are up.

  I don't understand how this is not a bigger issue for Ubuntu... We can't be the only ones with more complex network configs...

-Cheers, Peter.

[David Garland (davidgarland)]

Thanks Peter. I guess they don't make an issue of it if only 1 person
has reported the bug. I noticed when I added myself to the "this affects
me" it changed the status to confirmed. I actually had this working, but
then I'm pretty sure I did a apt-get upgrade or added a package and that
is when it broke.

Unfortunately, I didn't have date/time stamping added to my bash profile
so I can't tell from history when it was.

I also tried various Google references for adding static routes in an
automated fashion. While there were several differences in the approach,
none worked.

And I agree, I would think there has got to be other people doing
similar stuff. I didn't think I was that bleeding edge.

David Garland

On 11/18/2015 2:30 PM, Peter B wrote:
> Hi David,
> I could not reliably make things work for production. I had tried to put ifup/ifdown in my rc.local script and I tried tweaking the upstart scripts... but I couldn't get anything to bring up all the interfaces reliably.
>
> Noone in the forms bothered to help on this either...
>
> Upstart is a complete disaster... I ended up abandoning 14.04
> altogether, rolled back to a 10.04 snapshot and then forced an upgrade
> to 12.04 LTS. 12.04 is temperamental at times and also doesn't always
> bring up the interfaces right, but I can script around it and make sure
> things are up.
>
> I don't understand how this is not a bigger issue for Ubuntu... We
> can't be the only ones with more complex network configs...
>
> -Cheers, Peter.
>

[David Garland (davidgarland)]

Peter,

I resolved this. I came across a reference to a package available with Ubuntu called ifupdown-extras. It adds a file in /etc/network/ called routes. http://askubuntu.com/questions/168033/how-to-set-static-routes-in-ubuntu-server

I added the package and edited my /etc/network/interfaces to remove the post-up route statements and added them into the /etc/network/routes file as;

## Network for A

10.101.0.0 255.255.240.0 10.100.1.254 eth1
10.100.1.0 255.255.255.248 10.100.1.254 eth1

## Network for B
10.100.1.24 255.255.255.248 10.100.1.254 eth1
10.114.0.0 255.255.248.0 10.100.1.254 eth1

## Network for C
10.100.1.16 255.255.255.248 10.100.1.254 eth1
10.113.0.0 255.255.248.0 10.100.1.254 eth1

## Network for D
10.112.0.0 255.255.240.0 10.100.1.254 eth1

After multiple reboots the routes seem to be working each time.

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
10.100.1.0 10.100.1.254 255.255.255.248 UG 0 0 0 eth1
10.100.1.16 10.100.1.254 255.255.255.248 UG 0 0 0 eth1
10.100.1.24 10.100.1.254 255.255.255.248 UG 0 0 0 eth1
10.100.1.248 * 255.255.255.248 U 0 0 0 eth1
10.101.0.0 10.100.1.254 255.255.240.0 UG 0 0 0 eth1
10.112.0.0 10.100.1.254 255.255.240.0 UG 0 0 0 eth1
10.113.0.0 10.100.1.254 255.255.248.0 UG 0 0 0 eth1
10.114.0.0 10.100.1.254 255.255.248.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

Interesting note. I had a typo in one of the statements and because the gateway was not seen as a local interface, it did not add that route.

I'm not sure if this is a workaround or the intended function on Ubuntu's part based on the ifupdown-extra being available. Thought I'd pass it along.

David G

[long zhang (l-zhang)]

This bug also affects me on ubantu 14.04 and 15.10. Wonder will upgrade to 16.04 help or not?
I'm using
up route add ...
in my /etc/network/interfaces

[Russ Tndall (bobbysmith007)]

This bug is affecting me in ubuntu16.04 server
running neither

ifconfig down ens160 / ifconfig up ens160

nor

ip link set dev ens160 down / ip link set dev ens160 up

was causing our script to run. We tried in /etc/network/interfaces/ post-up and up and also in /etc/network/if-up.d/000-my-on-up-script.

My on-up script writes to a log and adds a route. The route nor the log messages show up, no matter how I bring the interface down and up. We were having trouble with neither post-up nor up working and I was trying to test.

We have been having missing routes after rebooting, so I was trying to resolve what was happening. I moved the command into a script that logs in /etc/network/if-up.d. No amount of up or down ran the script. However on a full restart I was able to see the if-up.d script run twice (once for each interface). That said I was unable to get it to run again with any up/downing.

I think there is a compounding factor, as I have a bunch of servers all basically configured the same way and all the rest are doing fine with "up" in the interfaces file commands. (Although not having to debug those, I don't know if the `ifconfig ensXXX up` command is rerunning the scripts correctly or not.

[Russ Tndall (bobbysmith007)]

I just spun up a different new server with the same network configuration (different ips, same post ups). It has an "up" command that has been specified in /etc/network/interfaces and worked on server boot. I added a script to /etc/network/if-up.d/000-up.sh that just logs when interfaces come up. When I execute the script or reboot the scripts run, but when I bring the interface down and then up, the scripts do not run.

Is there a reliable way to run scripts when an interface comes online?

[Russ Tndall (bobbysmith007)]

After more research:

This calls post up scripts:
 * ifdown ens160 && ifup ens160

These do not call post up scripts:
 * ifconfig ens160 down && ifconfig ens160 up
 * ip link set dev ens160 down && ip link dev set ens160 up

Is this intentional behavior I am misunderstanding. I had thought that all of these were synonymous and that the last was the current preference.

Sorry for the many posts, I thought I was done messing with it, but then had some more ideas.

[Russ Tndall (bobbysmith007)]

After more work and my previous discovery I found that ifup was throwing an error (RNETLINK: File already exists) that was caused by a duplicate "gateway" line in the interfaces file under the second interface. This caused a it to stop running the "up" scripts because it seemed to not have been correctly configured. The confusion was because the interface did actually come up, and was usable, but just wasnt being configured correctly. Apologies for my confusion.