failsafe.conf's 30 second time out is too low

[Scott Moser]

**** RELEASE NOTES ****

If a system has network interfaces defined in /etc/network/interfaces as "auto", the operating system will wait up to 120 seconds for those interfaces to be fully detected and configured before continuing to boot the system. Most users of Ubuntu will not be affected by this change, as only servers and dedicated workstations should have network interfaces configured in this way.

************************

as far as I can understand, the 30 second sleep in failsafe.conf means that /etc/init/rc-sysinit.conf will start within at most 30 seconds of 'filesystem' and 'ifup lo' having occurred.

I think that is really to small a number. You're only safeguarding against the case where a user had an entry in /etc/network/interfaces that where the device was removed or is not connected. Thats a very rare case. Increasing the timeout to 60 seconds would make it less likely to have a false positive and have rc-sysinit start early. (Ie, the case where a dhcp took 35 seconds).

The user will only be punished by waiting an additional 30 seconds in the case that they have a misconfigured or out of date /etc/network/interfaces.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: upstart 1.3-0ubuntu6
ProcVersionSignature: Ubuntu 3.0.0-9.14-generic 3.0.3
Uname: Linux 3.0.0-9-generic x86_64
Architecture: amd64
Date: Fri Sep 2 10:02:10 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100318)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: upstart
UpgradeStatus: Upgraded to oneiric on 2010-11-15 (290 days ago)

[Clint Byrum (clint-fewbar)]

Agreed Scott, I think we should wait a little longer. 2 minutes seems a reasonable amount of time, especially given that this should never affect the average laptop/desktop machine.

[Launchpad Janitor (janitor)]

This bug was fixed in the package upstart - 1.3-0ubuntu7

---------------
upstart (1.3-0ubuntu7) oneiric; urgency=low

  * debian/conf/failsafe.conf: raise timeout to 120 seconds to
    allow for very slow DHCP interfaces to come up on servers.
    (LP: #839595)
 -- Clint Byrum <email address hidden> Sun, 04 Sep 2011 09:29:27 -0700

[Leo Milano (lmilano)]

Hi

After installing this version of upstart is making, my netbook takes extra 100 seconds to boot. CTRL-ALT-F1 shows me that that the network security us being brought up. Any thoughts? Could this be a coincidence? Boot time (as measured with a script) has regressed incredibly over the last few days

Sun Aug 28 21:26:50 PDT 2011. Boot Time [s]: 43
Tue Aug 30 20:44:08 PDT 2011. Boot Time [s]: 40
Thu Sep 1 19:59:34 PDT 2011. Boot Time [s]: 39
Thu Sep 1 21:19:29 PDT 2011. Boot Time [s]: 38
Fri Sep 2 19:33:38 PDT 2011. Boot Time [s]: 39
Sat Sep 3 23:24:53 PDT 2011. Boot Time [s]: 76
Sat Sep 3 23:26:57 PDT 2011. Boot Time [s]: 68
Sat Sep 3 23:29:49 PDT 2011. Boot Time [s]: 67
Sun Sep 4 17:52:59 PDT 2011. Boot Time [s]: 162
Sun Sep 4 21:29:33 PDT 2011. Boot Time [s]: 156

Thanks
Leo

[Leo Milano (lmilano)]

Oh yes, changing that value in failsafe.conf brings back the old boot times:
tried setting to 12 and then 1, and it definitely fixed things: ( I added the //comments )

Wed Sep 7 17:13:34 PDT 2011. Boot Time [s]: 156 // Sleep 120
Wed Sep 7 18:59:59 PDT 2011. Boot Time [s]: 51 // Sleep 12
Wed Sep 7 19:04:28 PDT 2011. Boot Time [s]: 48 // Sleep 12
Wed Sep 7 19:10:36 PDT 2011. Boot Time [s]: 37 // Sleep 1

 This is how it looks now:

#################
santisofi@minime:~$ cat /etc/init/failsafe.conf
# failsafe

description "Failsafe Boot Delay"
author "Clint Byrum <email address hidden>"

start on filesystem and net-device-up IFACE=lo
stop on runlevel

pre-start exec sleep 1
#################

So, it looks like, around Sept 3, something changed with an update, and I started going to sleep for 30 secs (so boot times went around 30 sec longer). Then, this recent change to 120 added extra 90 secs. I looked around in dmesg and didn't find anything obvious. I will attach it shortly, regardless.

Thanks!
Leo

[Leo Milano (lmilano)]

One more thought, just by looking at the script and the behaviour on my system. The bug description states "as far as I can understand, the 30 second sleep in failsafe.conf means that /etc/init/rc-sysinit.conf will start within AT MOST 30 seconds of 'filesystem' and 'ifup lo' having occurred."

It seems to me that the sleep statement means that the bootup will take AT LEAST 30 seconds, and a 120 sleep statement will ensure at least 120 seconds to boot up.

I am not an expert, so sorry if this silly, but isn't upstart all about dependency based start up? It seems as if using sleep statements defeats the whole purpose of the system?

[Scott Moser (smoser)]

On Thu, 8 Sep 2011, Leo Milano wrote:

> I am not an expert, so sorry if this silly, but isn't upstart all about
> dependency based start up? It seems as if using sleep statements defeats
> the whole purpose of the system?

Could you please post your /etc/network/interfaces file ?

I suspect that you have a interface listed there as 'auto' that is not
plugged in. If that is the case, the correct solution for you is to
remove that line or comment it out. To be clear, I suspect you have
something like:
  auto eth0
  iface eth0 inet dhcp

but your eth0 is not plugged in.

[Leo Milano (lmilano)]

Yes, that's correct. Is that something that should not be there? Thanks!

santisofi@minime:~$ cat /etc/network/interfaces
# 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
auto eth0
iface eth0 inet dhcp

[Leo Milano (lmilano)]

Scott, is this how things are intended to work? My current understanding is:

* "pre-start exec sleep N" means "wait up to N seconds for the preconditions to be satisfied". In this case, these are a network up and a fs up. I thought it meant "Wait at least N seconds", but I guess I was wrong.

* The current change makes the system to wait up to 120 seconds if the network is not brought up according to /etc/network/interfaces

I think the latter is something that is not unlikely to happen for people who have been using different network managers and upgrading to new releases.

Why would we do this? Isn't it better to proceed with the boot up even if the network is not fully up? Why is a network fully up a requirement to run rc-sysinit.conf?

I would expect a flood of "my boot up takes 3 minutes" bug reports if this released with a potential two minute lag.

Thanks!
Leo

[Scott Moser (smoser)]

On Thu, 8 Sep 2011, Leo Milano wrote:

> Scott, is this how things are intended to work? My current understanding
> is:
>
>
> * "pre-start exec sleep N" means "wait up to N seconds for the
> preconditions to be satisfied". In this case, these are a network up and
> a fs up. I thought it meant "Wait at least N seconds", but I guess I was
> wrong.

No. 'pre-start exec sleep N' means that it will sleep for N in the
pre-start. And then nothing happens anywhere else (no 'start').

So basically all this job does is sleep for 120 seconds.

Then, rc.sysinit starts on :
  start on (filesystem and static-network-up) or started failsafe

So, it will start on the filesystem being available (which will happen
very early) and the network is up, *or* 120 seconds have passed since
'failsafe' started.

> * The current change makes the system to wait up to 120 seconds if the
> network is not brought up according to /etc/network/interfaces
>
> I think the latter is something that is not unlikely to happen for
> people who have been using different network managers and upgrading to
> new releases.

What network manager would have said to have that entry in
/etc/network/interfaces ? Even in the old behavior, having that entry
would stop NetworkManager from working for 'eth0'.
>
> Why would we do this? Isn't it better to proceed with the boot up even
> if the network is not fully up? Why is a network fully up a requirement
> to run rc-sysinit.conf?

Because things in svsvinit often expect (reasonably) to have a network.
Prior to there being upstart, the jobs there would have expected network,
and were sane in that expectation.

[Clint Byrum (clint-fewbar)]

I think this change may deserve a release note for 11.10, so that people who have kept an interface in /etc/network/interfaces for some reason aren't surprised by the long boot.

[Leo Milano (lmilano)]

@ Scott: thanks for the detailed response. It all makes sense now. I am guessing perhaps wicd wrote that entry in my interfaces file. I haven't edited this file by hand.

@ Clint: yes, I think it makes sense to add this to the release notes. Thanks for updating the description. It seems like this is a reasonable approach for now.

Longer term, I think the start system needs more granularity. Ideally, if the network is still not up, most services (except for things like ntp, firewalls, etc) should start anyway. The user should still be able to get X up and running, and be able to login. But the current structure of one upstart hook to all sysvinit services won't allow for that.

Thank you for the great work, and I hope this little extra bit of info benefits other users.

Best!
-- Leo

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Thu Sep 08 19:17:14 UTC 2011:
> @ Scott: thanks for the detailed response. It all makes sense now. I am
> guessing perhaps wicd wrote that entry in my interfaces file. I haven't
> edited this file by hand.
>
> @ Clint: yes, I think it makes sense to add this to the release notes.
> Thanks for updating the description. It seems like this is a reasonable
> approach for now.
>
> Longer term, I think the start system needs more granularity. Ideally,
> if the network is still not up, most services (except for things like
> ntp, firewalls, etc) should start anyway. The user should still be able
> to get X up and running, and be able to login. But the current structure
> of one upstart hook to all sysvinit services won't allow for that.
>

Anything that a user depends on having before X is up should be an
upstart job and have a very granular start up. This change should only
affect general network services.

If you look, X should already be independent of this delay. Here is the
start condition for lightdm:

start on (filesystem
          and started dbus
          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))

All of that can happen before runlevel 2 is emitted (which is all that is
actually blocked). I'm curious what your script measures as "boot time",
in the past, "able to log in" was used as the measurement.

> Thank you for the great work, and I hope this little extra bit of info
> benefits other users.

Leo, thanks for the heads up, I appreciate your testing and the feedback,
keep it coming!

[Leo Milano (lmilano)]

I will try to dig in a bit. My X clearly doesn't start until the penalty 120 secs expire, so I'd like to understand why, since for what you are saying this shouldn't be the case (and there is, indeed, a kdm.conf in /etc/init).

In the meantime: I use KDE, with KDM set to autologin to a user account. In that user account, I run the script I show below (in .kde/Autostart/). It basically runs an xterm, and then records the time since boot started. It gives me a measure of the time from cold boot into a usable desktop.

I will play a bit with lightdm, and will also try disabling autologin in KDM.

Cheers
-- Leo

#!/bin/bash
#
# 2009, Leo Milano
#
# Credits: http://www.perlmonks.org/?node_id=11582
# http://www.linuxscrew.com/2007/09/04/two-way-conversion-of-unix-time-seconds-since-1970-and-regular-time/
#

# Customize this if needed
log_file=~/boot_time.log

# A trick to make sure the script doesn't run this xterm in the background,
# we want the window to popup before we go on with the script
# Choose one of the dummy commands below
dummy=`xterm -e echo hi`

boot_time=`perl -ne 'print scalar $1 if /^btime (\d+)/' /proc/stat`
this_time=`date +%s`
let elapsed_time=this_time-boot_time

echo `date`. Boot Time [s]: ${elapsed_time} >> ${log_file}

[Leo Milano (lmilano)]

Hi,

Just an update: Lightdm also gets penalized and waits the sleep time declared in failsafe.conf before loading

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Fri Sep 09 04:22:22 UTC 2011:
> Hi,
>
> Just an update: Lightdm also gets penalized and waits the sleep time
> declared in failsafe.conf before loading
>

Very interesting. I'd be curious to see your /var/log/boot.log with
--verbose added to the boot commandline, as I wouldn't expect any of those
start procedures to block on runlevel 2, but maybe I missed something.

[Leo Milano (lmilano)]

Clint, I'll give it a swirl. Where exactly do you add --verbose? Do you mean to remove the "quiet" linux boot parameter? Or add splash=verbose ?

Thanks!

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Fri Sep 09 12:41:00 UTC 2011:
> Clint, I'll give it a swirl. Where exactly do you add --verbose? Do you
> mean to remove the "quiet" linux boot parameter? Or add splash=verbose
> ?

In grub, yes remove 'quiet' and replace it with '--verbose'

It may also be interesting to see the contents of

grep init: /var/log/syslog

right after this event.

>
> Thanks!

No thank you!

[Leo Milano (lmilano)]

Will do. I assume you mean to run a grep on syslog right after I login (or pls let me know otherwise).

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Fri Sep 09 16:16:57 UTC 2011:
> Will do. I assume you mean to run a grep on syslog right after I login
> (or pls let me know otherwise).
>

Right, to clarify

at grub scren, edit cmdline and remove 'quiet', add '--verbose'

After booting up, attach two things to this bug:

/var/log/boot.log

and

grep init: /var/log/syslog

[Robert Hooker (sarvatt)]

So this seems to be hitting every one of my machines after the last round of updates, and removing eth0 from /etc/networking/interfaces does indeed fix the 2 minute pause before the desktop comes up. That entry exists for every machine that's had a network cable plugged in in the past (with available to all users checked in network-manager) doesn't it? Making this much higher impact than the report states. I never added it on any machine here but it affects all 7 oneiric laptops I used after the latest upgrades.

[Chris Van Hoof (vanhoof)]

I can confirm Robert's workaround in Comment #22 does fix-up this delay when booting. I /just/ upgraded from natty to Oneiric today and instantly ran into this issue on a Lenovo x220, which has in the past (not often) made use of the onboard ethernet.

--chris

[Leo Milano (lmilano)]

Robert, Chris, I think you are both hitting also the other problem I encountered, namely the fact that X is not starting until failsafe is up (even though theoretically this should not be the case).

Could you please look at comment #21 by Clint and post the info he is asking for as well? I will, later today, but I am guessing the more the merrier, since this looks like it would become a high impact issue (I am glad we found it)

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Fri Sep 09 18:55:11 UTC 2011:
> Robert, Chris, I think you are both hitting also the other problem I
> encountered, namely the fact that X is not starting until failsafe is up
> (even though theoretically this should not be the case).
>
> Could you please look at comment #21 by Clint and post the info he is
> asking for as well? I will, later today, but I am guessing the more the
> merrier, since this looks like it would become a high impact issue (I am
> glad we found it)
>

Ok, so I took a second look and now I realize that the display managers all
delay their startup until runlevel 2 with something like this (from lightdm)

    if [ -n "$UPSTART_EVENTS" ]
    then
        [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/lightdm" -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ] || { stop; exit 0; }

        if [ "$RUNLEVEL" = S -o "$RUNLEVEL" = 1 ]
        then
            # Single-user mode
            plymouth quit || :
            exit 0
        fi
    fi

That actually does make sense as the whole point of the transition from
S -> 2 is to signal that the system is ready for users to log in.

No need for any of that debugging info, I see whats going on.

Is there any actual reason to have 'auto eth0' in there if you're not
going to wait for it to come up? If its really a dynamic interface that
isn't always plugged in, it should be configured via network manager or
brought up and down manually, no? Was the intention that it would just
run dhclient on it forever and get an address if and when it was plugged
in? That still seems like a job for network manager, though I could be
swayed on that.

Maybe we should change update manager to detect this situation and
display the release note? That seems a bit heavy handed though.

At this point I'm still thinking we should leave it as it is, but possibly
change the wording and priority of the release note.

[Leo Milano (lmilano)]

Clint. The biggest issues it that we are not sure, but it is plausible that a large proportion of the existing systems will suffer a 2 minute delay after the upgrade. How about we test this:

* remove the offending ethN line from /etc/networking/interfaces
* reboot
* connect the laptop/desktop to an ethernet device at some point, to see if network manager is actually adding that entry again, which is what Robert suggested in #22

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Fri Sep 09 20:22:53 UTC 2011:
> Clint. The biggest issues it that we are not sure, but it is plausible
> that a large proportion of the existing systems will suffer a 2 minute
> delay after the upgrade. How about we test this:
>
> * remove the offending ethN line from /etc/networking/interfaces
> * reboot
> * connect the laptop/desktop to an ethernet device at some point, to see if network manager is actually adding that entry again, which is what Robert suggested in #22
>

Its ok if 'eth0' *appears* in /etc/network/interfaces. What causes the
wait is if there is an 'auto eth0'.

NetworkManager should *not* be adding auto interfaces to that
file. There's really no reason, whatsoever, for it to do that.

I'm wondering if people are just seeing this because they've added
interfaces for things like libvirt and such.

Still not convinced this needs changing beyond strong wording in the
release notes. Possibly also we could display a plymouth message
after 30 seconds of waiting, something like 'Waiting for network
interfaces...' so people know what is causing the slowdown.

[Robert Hooker (sarvatt)]

I still haven't figured out what's creating it, but even a new machine installed from beta 1 with an ethernet cable plugged in, pulling the ethernet cable and and dist-upgraded over wifi the next boot is hitting the problem because auto eth0 is in there. Ubiquity when you check update/install third party during the install might be what it is.

[Chris Van Hoof (vanhoof)]

Just as a side note on how I installed this machine initially ... to get partition alignment setup properly (using ssd here), I pre-partitioned the disk, then used the natty-alternate install with the onboard ethernet connected ... Perhaps that is how I've ended up with eth0 in /etc/networking/interfaces ... Certainly not something I have ever added on my own.

--chris

[Leo Milano (lmilano)]

Three is a crowd! I have 4 machines running kubuntu. Two started out with regular CD/USB live image installed to disk. The other two were installed from the netinstall mini-iso, connected to ethernet. These two are the only ones where I see an auto ethN.

I also played in one of my machines extensively with the network management plasma widget and the ethernet config (as I suggested in post #26). I could never, ever get it to save anything to the /etc/network/interfaces files.

It seems pretty conclusive that some of the ubuntu official installers are adding these auto ethN entries, which don't seem to make sense. Should we open a bug report for that? What's the proper place?

In addition, I agree with Clint that the more e can do to help users hitting this the better. It will be a minority, but definitely a lot of people. Is it possible to have the update manager to actually correct this, save a back up of the offending interfaces files, and people the info on how to restore it if needed? Sames as happens when you upgrade KDM or GDM and it gives you the option to keep the custom config file or use a new one (with additional info pointing at the issue at hand)

Cheers!
Leo

[Robert Hooker (sarvatt)]

ubiquity has source specifically for managing /etc/networking/interface (d-i/source/netcfg/write_interface.c) so it seems whatever I am doing during the install is the wrong way to do it. Sorry for the red herring in network-manager, it was just a likely guess since that was the only thing I touched on one of the machines after a clean beta 1 install to set up the wifi network.

[John Lenton (chipaca)]

I can confirm I had 'auto eth0' in /etc/network/interfaces on my notebook, and I don't think I've put them there myself.

Furthermore, I just installed 11.04 in a VM, and /etc/network/interfaces has a "auto eth0" line.

[Timo Jyrinki (timo-jyrinki)]

I've a fresh Oneiric Beta 1 installation and because of this sleep command I thought either my Ubuntu or laptop itself is broken. See my report bug #845914. I installed Ubuntu from the alternate CD.

[Jeremy Bícha (jbicha)]

Could either a new bug for this issue be opened or this bug's status be changed away from "Fix Released"? All but 3 of the comments have been posted after this was "fixed".

[Leo Milano (lmilano)]

Jeremy: "Could either a new bug for this issue be opened or [...]"

Done!
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/839595

[Leo Milano (lmilano)]

Sorry for the typo in my last statement, the new bug report is bug #847782

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/847782

[GeekSmith (lixo-geeksmith)]

Manual symlink of /var/run->/run and /var/lock-/run/lock fixed my issues.

[ilf (ilf)]

I don't like this behavior.

I have eth0 auto in /etc/network/interfaces, so that it gets auto-enabled when plugged in.
This being a laptop it gets moved around and doesn't always have an ethernet connection plugged in.
No I'm supposed to wait two minutes on every boot OR not have the interface connected?
Both are no real options for me.

What does this mean?
> only servers and dedicated workstations should have network interfaces configured in this way

How else should I have my interface configured?
BTW, I do not run Gnome, KDE or any other of those desktop environments. I do not have NetworkManager installed and won't install it for this.

I deleted my /etc/init/failsafe.conf for now.
But I really think this behavior shouldn't be forced.

[Clint Byrum (clint-fewbar)]

Excerpts from ilf's message of Fri Oct 14 18:11:56 UTC 2011:
> I don't like this behavior.
>

Hi ilf, sorry that you're experiencing problems with this change.

This behavior is meant to provide a balance between mobile systems and
servers/dedicated workstations.

The former needs flexible network management, which ifupdown really
doesn't provide, and the latter needs to be able to define a reliable
network configuration.

Your case where a mobile system that does want to use ifupdown to manage
a mobile connection instead of network-manager is normally handled by
the failsafe boot.

A suggested simple workaround is to remove the 'auto eth0' and instead
add an upstart job like this:

start on net-device-added INTERFACE=eth0
task
exec ifup eth0

This will bring up your interface as soon as the hardware is available,
but will not block the boot waiting for it to be up.

We can't really make this the default and still provide reliable
configuration for workstations and servers because we have no way to
know that you intend for an interface to be transient if you did not
install network-manager.

> I have eth0 auto in /etc/network/interfaces, so that it gets auto-enabled when plugged in.
> This being a laptop it gets moved around and doesn't always have an ethernet connection plugged in.
> No I'm supposed to wait two minutes on every boot OR not have the interface connected?
> Both are no real options for me.
>
> What does this mean?
> > only servers and dedicated workstations should have network interfaces configured in this way
>
> How else should I have my interface configured?
> BTW, I do not run Gnome, KDE or any other of those desktop environments. I do not have NetworkManager installed and won't install it for this.
>

network-manager does not require a GUI.

You can use network-manager without a GUI via nmcli and hand edit
/etc/NetworkManager/system-connections/*, or you can use connman.

Note that if you have X, you can also just install and make use of
network-manager-gnome without having to use all of gnome.

> I deleted my /etc/init/failsafe.conf for now.
> But I really think this behavior shouldn't be forced.
>

This is going to make it so your system will never boot without eth0
plugged in. I'd suggest the ifup workaround above instead.

[ilf (ilf)]

Thanks for your workaround, using that now.

I still think it's wrong to assume that one of these three has to exist on a system:
- auto eth0 and eth0 always plugged in
- network-manager installed
- boot time delayed by two minutes.

And no, I won't install network-manager even if it doesn't depend on X.

[Clint Byrum (clint-fewbar)]

Excerpts from ilf's message of Fri Oct 14 21:50:25 UTC 2011:
> Thanks for your workaround, using that now.
>
> I still think it's wrong to assume that one of these three has to exist on a system:
> - auto eth0 and eth0 always plugged in
> - network-manager installed
> - boot time delayed by two minutes.
>
> And no, I won't install network-manager even if it doesn't depend on X.
>

ilf, if you have ideas for how we can identify interfaces as non-critical
then please do suggest them. I think that deserves a new bug report
explaining exactly what you expect to have happen, as this bug report
is effectively closed. I would suggest reporting that bug against the
ifupdown package..

[ilf (ilf)]

The workaround only fixes the waiting time.
It disables auto-up of the interface, which I want, if it us plugged in. This is a regression and still a major annoyance for me.
Closing this bug report is not right, this isn't the fault of ifupdown, but upstart.

[Clint Byrum (clint-fewbar)]

Excerpts from ilf's message of Sun Oct 23 13:05:31 UTC 2011:
> The workaround only fixes the waiting time.
> It disables auto-up of the interface, which I want, if it us plugged in. This is a regression and still a major annoyance for me.
> Closing this bug report is not right, this isn't the fault of ifupdown, but upstart.
>

ilf, this was an intentional change in behavior and documented in the
release notes. I understand it has made your particular use case a
bit more difficult to achieve. I do see a need for a second group in
/etc/network/interfaces called something like auto-nowait that will
be brought up at boot time but not waited on. I would encourage you to
open a new bug report as a feature request for this. Its a corner case,
but one that I think we can support for you as a user. Even better, you
can probably submit a patch and we should be able to add it for 12.04.

You can achieve it yourself by changing the line in /etc/network/interfaces

from

auto eth0

to

allow-nowait eth0

and then edit /etc/init/network-interface.conf to run

ifup --allow nowait $IFACE

Just before the exec of ifup.

This will ensure that your interface is brought up, but not waited on
in the boot sequence.