network services at boot (was Re: Boot charting)

Matthew East wrote:

>On Sun, 2005-11-13 at 18:02 +0000, Matthew East wrote:
>  
>
>>On Sun, 2005-11-13 at 18:27 +0100, Oliver Grawert wrote:
>>    
>>
>>>hi,
>>>On So, 2005-11-13 at 16:10 +0000, Matthew East wrote:
>>>      
>>>
>
>  
>
>>To be honest I am actually quite pleased with boot times (45 seconds is
>>fine for me, and since suspend to ram works too...), the only thing that
>>really constitutes a problem is the fact that the network ifup service
>>stops for ages while I am not within range of my home network (for
>>example if I move to the office) and this then leads to the ntpdate
>>service losing lots of time too. I use profiles in network-admin, but of
>>course this doesn't help on boot.
>>
>>On Windows, one of the reasons it is quicker at booting is (I think)
>>that it doesn't hang around waiting for the network services to start
>>up. Then again, it takes a hell of a lot longer to log in on Windows
>>than to log into Gnome. :)
>>    
>>
>
>Idea: would it be possible to remove the ntpdate service from startup
>altogether? I've noticed that update-manager manages to reload my apt
>sources in the background after I've entered my password for other
>administrative services, perhaps it could be taught to update the clock
>from the internet via ntpdate too? Users should be able to disable that
>from the Time & Date administrative tool.
>
>This to me would make more sense than running it at boot when loads of
>people don't have the internet up. In many cases, the ntpdate services
>doesn't fail quickly: it can keep searching for ages!
>
>Probably this idea has occurred to you guys before and you've rejected
>it for some reason, if so, please ignore me. But I think on the face of
>things it would be a sensible solution.
>
>Matt
>  
>
I think we can leave ntpdate where it is, but make the script smarter
and check if we have an interface up that's likely to provide internet
access (i.e. ethX, whatever the wireless interfaces are called). 

For dhcp, there are two options that we should investigate.  If you take
a look at the dhclient.conf man page, you see that you can specify a
specific timeout.  The default is 60 seconds, any reasonable dhcp server
will respond much faster then that.  I don't think cutting that down to
30, or even less would be unreasonable.  Also, dhclient has a flag
'-nw'.  This forces it to go straight to daemon mode without waiting for
an ip address however this is problematic for network dependend services
that come after.

Yi