[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: configuring interface & configuring MTA time out



On Wed, 13 Jun 2012 12:32:55 -0400, Gilbert Sullivan wrote:

> On 06/13/2012 10:43 AM, Camaleón wrote:
>> On Mon, 11 Jun 2012 13:44:22 -0400, Gilbert Sullivan wrote:
>> 
>> (...)
>>  
>>> Until the recent update (a couple of weeks ago) of netscript which
>>> removed ifupdown, the system just always booted quickly on any of its
>>> various network locations. Since then, when I have set Wicd to connect
>>> to one of the fixed IP address locations, the boot process halts for
>>> one minute at two places -- the configuring interface line, and the
>>> configuring MTA line. (I'm guessing the configuring MTA time out
>>> happens because the configuring interface time out precedes it.)
>> 
>> Yes, that's likely what happens. The MTA daemon has to wait until it
>> gets a valid networking configuration and can delay the booting process
>> when there's a problem with it.
>> 
>> 
> Thank you, Camaleón, for getting back to me.
> 
> I may not have stated my situation very clearly. This is a notebook that
> travels with me from site to site. At some sites DHCP is not used, and
> I'm assigned a fixed IP address. 

(...)

How are you doing that? Are you using some kind of dhcp-client fallback 
configuration mode to provide the network card settings manually when no 
DHCP server can be contacted at the defined interval? Or are you using 
WICD capabilities to configure the network? 

This is important because WICD looks for files different from the usual 
ifup method so we first need to know how is your network interface being 
configured and what can be tweaked from what files.

> It is only at those sites where I experience the two 60 second delays
> (network interfaces, MTA) in boot process. I'm just confused as to why
> the delays just started happening. I've had the /etc/network/interfaces
> file configured that way for years, and the boot process at all sites
> -- whether using fixed IP address or DHCP -- was always quick. No
> timeouts.

Okay, I think I see now the problem (thanks for clarifying!): networking 
service timeouts -or takes too much time- because no DHCP server is in 
place and then "it does something" that's what we need to analyze to see 
a way on how to speed it up. Is that right? :-)

Greetings,

-- 
Camaleón


Reply to: