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

Re: configuring interface & configuring MTA time out



On 06/15/2012 10:35 AM, Camaleón wrote:
> On Thu, 14 Jun 2012 14:44:57 -0400, Gilbert Sullivan wrote:
> 
>> On 06/14/2012 01:34 PM, Camaleón wrote:
> 
>>> To be sincere, I don't know what's originating the problem. If you say
>>> the network settings are properly configured, why Exim4 is that lazy?
>>> :-?
>>>
>>> Searching for "exim boot speed up" in Google I found this:
>>>
>>> ***
>>> 1.3.7. Why does exim take such a long time to start?
>>> http://wiki.debian.org/PkgExim4UserFAQ#Why_does_exim_take_such_a_long_time_to_start.3F
>>> ***
>>>
>>> Check if any of the suggested tips helps to mitigate the pain.
>>>
>>>
>> Hi, Camaleón.
>>
>> I'm coming to the conclusion that, when Wicd is set to use a profile
>> with a fixed IP address, the system is actually only connecting to the
>> network as it actually comes up to the desktop (after login). That would
>> be why exim4 is timing out on the fixed IP address profiles and working
>> just fine on the profiles that are set to use DHCP.
> 
> To me sounds a bit unrealistic the fact a static network configuration 
> can take longer than a dynamic one... Does not compute :-)
> 

I know, but it's true. Not sure why, but it's true.

>> The use of dc_minimaldns='true' didn't work to improve the situation,
>> but it did cause the boot process to squawk. (It said that
>> dc_minimaldns='true' will not work.) I've restored the exim4
>> configuration and /etc/dhcp/dhclient.conf to their default settings for
>> now.
> 
> The wiki article included more tips you can try from the Exim's side.
> 

The FQDN tip didn't work, and I didn't think that the IPV6 tips were
appropriate, since none of these networks uses it, and my notebook isn't
set up to use it by default.

> Anyway, I'd also run the following tests:
> 
> 1/ Just for testing purposes, you can momentary disable wicd and test 
> with a static IP configuration defined at "/etc/network/interfaces". If 
> this boost the booting process then we can center exclusively in WICD 
> (I still have my doubts about what is causing this).
> 
> (if 1/ makes no difference, stop here as we will have to find another 
> culprit other than WICD, otherwise proceed with 2/)
> 

Yup, I set Wicd up to not start at boot, and I configured static IP in
/etc/network/interfaces. At the next reboot, I saw the same 60 sec.
delay in configuring interface and the 60 sec. delay for starting MTA.

> 2/ Ensure there's only one network daemon running (i.e., no n-m, no 
> dhcpd, no networking services) to avoid any possible collision.
> 

I checked, just to be sure. No other GUI network manager has ever been
installed on the system.

> 3/ Test with a fresh-new created user (configure WICD for him and boot), 
> to discard something wrong with your current user configuration files for 
> WICD.

Done, and no difference.

> 
>> I think that the problem I'm seeing is a temporary (I hope) glitch
>> between netscript and Wicd, and that it'll probably be resolved at some
>> point by upgrades. 
> 
> You look very optimistic :-P
> 

I'm trying. ;-)

>> That may take a while, though, because Wicd doesn't seem to be under
>> terribly active development. Maybe I'll try to get in touch with the
>> Debian maintainers for the two packages. Something tells me that the
>> packages aren't working together the way they expect them to, and that
>> it may be counterproductive to start changing default configurations
>> that have been working just fine for years.
> 
> As you are running wheezy (and considering the freeze is going to be in 
> about a few weeks) consider in opening a bug report.
>  

I'm thinking of doing that. I guess I'll file a bug against netscript.
The problem may not be there, but it sure as heck started when the
recent netscript upgrade was installed.

>> In the meantime, until I get a chance to really get into it, I can just
>> continue to use <Ctrl>+<C> at the "configuring interface" prompt. The
>> system boots up as quickly as normal, and everything appears to be
>> working.
> 
> If Exim4 is started afterwards, then there should be no other gotchas.
> 

Yes, Exim4 is starting up properly, and everything seems to be going well.

I'll run bugreport and file against netscript to see what happens.

Thank you for your ideas, and I'll return to this thread when I have any
kind of information.

Best regards,
Gilbert


Reply to: