ifupdown doesn't bring loopback to state up

[xxxx]

Upon booting a machine with the following setup on a relatively slimmed down netboot machine the loopback interface isn't brought up properly:

cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface lo inet6 loopback

auto eth0
iface eth0 inet6 auto
dhcp 1
#iface eth0 inet ipv4ll

auto eth1
iface eth1 inet6 auto
dhcp 1
#iface eth1 inet ipv4ll

Upon boot Loopback is unconfigured:
root@<hostname>:~# ip addr show dev lo
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Try to bring the interface up:
root@<hostname>:~# ifup -v lo
ifup: interface lo already configured

Bring it down and up:
root@<hostname>:~# ifdown -v lo
Configuring interface lo=lo (inet)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/avahi-autoipd
run-parts: executing /etc/network/if-down.d/upstart
run-parts --verbose /etc/network/if-post-down.d
Configuring interface lo=lo (inet)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/avahi-autoipd
run-parts: executing /etc/network/if-down.d/upstart
run-parts --verbose /etc/network/if-post-down.d
Configuring interface lo=lo (inet6)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/avahi-autoipd
run-parts: executing /etc/network/if-down.d/upstart
run-parts --verbose /etc/network/if-post-down.d

root@<hostname>:~# ifup -v lo
Configuring interface lo=lo (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
Configuring interface lo=lo (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
Configuring interface lo=lo (inet6)
run-parts --verbose /etc/network/if-pre-up.d
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart

no change:
root@<hostname>:~# ip addr show dev lo
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

bring it down again:
root@<hostname>:~# ifdown lo

And up, but this time with --no-loopback:
root@<hostname>:~# ifup -v --no-loopback lo
Configuring interface lo=lo (inet)
run-parts --verbose /etc/network/if-pre-up.d
ip link set dev lo up
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
Configuring interface lo=lo (inet6)
run-parts --verbose /etc/network/if-pre-up.d
ip link set dev lo up 2>/dev/null
ip addr add dev lo ::1 2>/dev/null
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart

now it seems like something actually happened!

check:
root@<hostname>:~# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

All seems fine, everything is working from here on.

My expectation is that ifup should configure the interface and set state to up, and ifdown should set state to down, even though it's a loopback that may or may not be magically autoconfigured somewhere else.

And a question:
If the case is that ifup shouldn't configure the loopback, what should configure it?

[xxxx (xxyxyxyxyyxyy-deactivatedaccount)]

I forgot to include, other interfaces (eth*) are configured as expected upon boot:

root@<hostname>:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:9c:02:ab:cb:d8 brd ff:ff:ff:ff:ff:ff
    inet6 my:ipv6:address:1/64 scope global temporary dynamic
       valid_lft 603348sec preferred_lft 84348sec
    inet6 my:ipv6:address:2/64 scope global dynamic
       valid_lft 2591995sec preferred_lft 604795sec
    inet6 fe80::29c:2ff:feab:cbd8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:9c:02:ab:cb:d9 brd ff:ff:ff:ff:ff:ff
    inet6 my:ipv6:address:3/64 scope global temporary dynamic
       valid_lft 603348sec preferred_lft 84348sec
    inet6 my:ipv6:address:4/64 scope global dynamic
       valid_lft 2591995sec preferred_lft 604795sec
    inet6 fe80::29c:2ff:feab:cbd9/64 scope link
       valid_lft forever preferred_lft forever

[xxxx (xxyxyxyxyyxyy-deactivatedaccount)]

I found an upstream bugreport detailing the actual issue in ifupdown source on debian's bugtracker here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757291

[Stéphane Graber (stgraber)]

Fix uploaded to utopic.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ifupdown - 0.7.48.1ubuntu5

---------------
ifupdown (0.7.48.1ubuntu5) utopic; urgency=medium

  * Fix broken loopback handling due to incorrect patching of the Debian
    source. (LP: #1375821)
 -- Stephane Graber <email address hidden> Wed, 01 Oct 2014 11:43:43 -0400

[xxxx (xxyxyxyxyyxyy-deactivatedaccount)]

Will this be updated in trusty as well?

[telmich (nico-launpad-net)]

Hello,

we are a hosting provider in Switzerland and are running some Ubuntu 14.04. instances. This bug hits some of our customers, as essentially services on localhost are unavailable.

This pretty much renders *any* service useless that accesses another service on the same box (i.e. breaks mailman setup, breaks nginx proxy configurations, ...).

I wonder if this can be fixed quickly for trusty?

Cheers,

Nico

[Launchpad Janitor (janitor)]

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

[Alex Gottschalk (alex-gottschalk)]

This bug also prevents the mounting of NFS shares on boot, because rpcbind is unable to start without the lo interface.

[Simon Eisenmann (longsleep)]

Guys this fix really needs to be in trusty too.

[Simon Eisenmann (longsleep)]

All right, just found a simple workaround for trusty. Just install the "net-tools" package and lo will be brought up correctly.

[xxxx (xxyxyxyxyyxyy-deactivatedaccount)]

yeah. but net-tools is deprecated, so this really should be fixed in all releases. :)

[Alex Gottschalk (alex-gottschalk)]

Please port this fix to trusty

[Alex Gottschalk (alex-gottschalk)]

Feel free to retweet this

https://twitter.com/An0Theral/status/675127147082686464

[Dariusz Gadomski (dgadomski)]

I have backported the fix to trusty in my ppa.

Unfortunately I was not able to reproduce this issue (although my tests are ongoing). With that being said I would really appreciate anyone that is affected by this issue to give it a try and let me know whether the backport fixed that for them.

The ppa with the backport is ppa:dgadomski/lp1375821

Thank you!

[xxxx (xxyxyxyxyyxyy-deactivatedaccount)]

Hi!

I've tested your patch, and it's still using ifconfig in network-interface.conf
it should use ip instead.

what's in network-interface.conf:
 ifconfig lo 127.0.0.1 up || true
what should be in network-interface.conf:
       ip link set dev lo up || true

[Robie Basak (racb)]

There doesn't seem to be any action needed against mailman, so I'm marking that task Invalid and accepting an SRU task for Trusty.

[Utkarsh Gupta (utkarsh)]

Hello, Trusty reached "End of Standard Support" a while ago and so I am marking this as "Won't Fix". Thank you.