Boot is delayed due to missing static network interface

Bug #964775 reported by Michael Hope on 2012-03-25
48
This bug affects 7 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Undecided
Unassigned
upstart (Ubuntu)
Medium
Unassigned

Bug Description

/etc/init/failsafe.conf gets stuck waiting for the static interfaces in /etc/network/interfaces to come up as one of them is a hotplug device.

I have a BeagleBone which shows up as a USB Ethernet gadget and a rule in interfaces to set the IP addresses when it's plugged in. The rule is:

auto usb9
iface usb9 inet static
        address 192.168.7.1
        netmask 255.255.255.0
        up echo 1 > /proc/sys/net/ipv4/ip_forward
        up iptables -P FORWARD ACCEPT
        up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24
        down echo 0 > /proc/sys/net/ipv4/ip_forward
        down iptables -t nat -F POSTROUTING

upstart waits for ths interface to be configured but as the device isn't there it never gets configured. Eventually failsafe kicks in but it adds 2 minutes to the boot.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: upstart 1.4-0ubuntu9
ProcVersionSignature: Ubuntu 3.2.0-19.30-generic 3.2.11
Uname: Linux 3.2.0-19-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Mon Mar 26 09:40:56 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120219)
ProcEnviron:
 SHELL=/bin/bash
 TERM=xterm
 LANG=en_NZ.UTF-8
 LANGUAGE=en_NZ:en
SourcePackage: upstart
UpgradeStatus: No upgrade log present (probably fresh install)

Michael Hope (michaelh1) wrote :
Changed in upstart (Ubuntu):
importance: Undecided → Medium
Clint Byrum (clint-fewbar) wrote :

I wonder if we could emit failsafe-boot on 'stopped networking'. At that point, udev has done its thing, and ifup -a has tried to bring up any network interfaces that exist. So in theory, there's nothing left to wait for even if there are auto interfaces not up yet.

Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu):
status: New → Confirmed
nadrimajstor (ipejic) wrote :

As I migrated from Lucid to Precise there was quite a bump when I realized that following lines:
auto eth0
auto eth1
would unsuspectingly have quite an impact on boot time if one of cables is currently unplugged.

Users who use mobile phones with auto/static configurations also have same problem when phone is not attached.

Clint Byrum gave some nice ideas for workarounds in https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/839595/comments/39

If you ask me as a user I would prefer to have seamless transition and expect same behavior from "auto".

However, introducing auto-nowait will also be not quite so obvious but nice/easy-to-use/grasp solution.

Please keep trying to make Ubuntu usable by mere mortals and thank you for your patience.

Gary Houston (ghouston) wrote :

I think the default behaviour should be that network problems shouldn't block login. The exception may be a dedicated workstation with remotely mounted home directories, where you may want it to block forever. The current compromise of waiting 120s isn't correct for either situation.

There's also the issue of server processes which shouldn't be started until the network is up, and this seems to be one of the motivations for the change to a 120s timeout.

Is it a matter of chaining the upstart dependencies differently? Networking problems may need to block certain server processes but not block logging in. It should be easy to alternatively configure the system (presumably by changing one of the upstart files) so that network problems do block login.

Sworddragon (sworddragon) wrote :

The boot is still delayed even with systemd 232-21ubuntu2 on Ubuntu 17.04 dev if something causes the network not to get up (for example as it is happening here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1681190 ). Also the time the job does now wait (as shown) seems to be 5 minutes and 2 seconds which looks a bit crooked to me (I would expect something like 5 minutes then).

Sworddragon (sworddragon) wrote :

Edit: Now at the next boot the maximum time the job shows to wait was 5 minutes and 3 seconds so the time seems to get a bit generated for some reason.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers