That is really interesting, there was a similar fix in the networking script in
Ubuntu 10.10 that was discussed on the Ubuntu forums, but this must be why it
has never been implemented. The modified networking script does work on my
system, but it is a simple home laptop (Dell C840) installation with no
dependency on a network connection. It even boots a couple of seconds or so
faster.
In Debian 6 when I investigated this I used another method I kept notes on:
It is also possible to recompile ifup so dhclient is started with the -nw
option by modifying the inet.defn file then compiling and installing the new
binary.
Just rename the old /sbin/ifup to /sbin/originalifup.bak and copy the new ifup
to /sbin and it works as before, using the Debian source package.
Ifupdown: Version: 0.6.10
Change this section in inet.defn so it includes -nw as shown below:
up
[[ifconfig %iface% hw %hwaddress%]]
dhclient3 -pf /var/run/dhclient.%iface%.pid -lf
/var/lib/dhcp3/dhclient.%iface%.leases %iface% \
if (execable("/sbin/dhclient3"))
dhclient -v -nw -pf /var/run/dhclient.%iface%.pid -lf
/var/lib/dhcp/dhclient.%iface%.leases %iface% \
elsif (execable("/sbin/dhclient"))
pump -i %iface% [[-h %hostname%]] [[-l %leasehours%]] \
elsif (execable("/sbin/pump") && mylinuxver() >= mylinux(2,1,100))
udhcpc -n -p /var/run/udhcpc.%iface%.pid -i %iface% [[-H %hostname%]] \
[[-c %client%]] \
elsif (execable("/sbin/udhcpc") && mylinuxver() >= mylinux(2,2,0))
dhcpcd [[-h %hostname%]] [[-i %vendor%]] [[-I %client%]] \
[[-l %leasetime%]] %iface% \
elsif (execable("/sbin/dhcpcd"))
There are various dependencies required to compile this package though. There
are no real advantages to doing this except dhclient prints a few lines without
delaying
the boot, making it convenient for tracing the problem in syslog and bootlog.
I did consider at the time how it would be possible to pass the -nw option to
dhclient from ifup, adding it to the environment variables when dhclient was
exec'ed, but never did anything about it as it seemed overcomplicated. Then the
-nw option could be specified in the init script and the command line would
operate as normal. But this would still allow the boot to proceed without
actually making a connection to the internet.
There is a flaw in this concept you describe though, as dhclient 'goes daemon'
regardless after 1 minute, whether it has made a connection or not. Also it
only delays boots on random occasions, so if the intention is to delay boot
until a network connection is established then it has failed in this too. But
perhaps you refer to completing the other items started by the networking
script and ifup, and the fact that dhclient is started would be sufficient to
allow the boot to proceed. If you had a permanently on ethernet connection you
would probably not notice anything anyway, but with a wireless connection which
may often be used offline with the AP off it can be quite apparent. Even with
the AP on it can take a while to establish a connection.
The above ordering in inet.defn is outdated too, as the latest dhclient is now
called dhclient, with dhclient3 being the previous version. But this is from
the Debian 6 source package for ifupdown, I have not had cause yet to check out
the source in 7, which I installed from CD only about a month ago.
I don't have a patch to do this currently, as I just considered the
possibility, and it might take some thought to get the -nw through all that
execle section and into the options for dhclient correctly! It looked possible
though.
'sysvinit' itself will place the runlevel 1 scripts in the background and
redirect stdin and stderr to /dev/null when runlevel 2 starts, so I am not sure
that doing this explicitly in the init script is so different, the problem
arises with the superfast execution from readahead fedora having previously
placed all the files into RAM which allows dhclient to run earlier than it
usually does. The point is that the networking script takes so long to complete
it is still going when Runlevel 2 has started, odd though this seems, I traced
this behaviour with various logging methods over several weeks last year. But
there are other init packages, so passing the -nw option as appropriate could
be the most precise method of fixing the issue.
dhclient itself seems blameless in this though, it is just behaving according
to the options it is given.
