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. 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. >> My /etc/network/interfaces file on this system is: > > (...) > >> allow-hotplug eth0 >> iface eth0 inet dhcp > > So you're using dhcp for eth0... then the origin of the delay could be > your system is waiting for a lease. To confirm this point, configure a > static network layout in your "/etc/network/interfaces" file instead > using dhcp, reboot and check for any difference in the time it takes now. > Yes, I'm sure of this. Unfortunately, the fixed IP addresses used by this system are not the same ones everywhere. That means I'd have to have a separate /etc/network/interfaces file for each one. Actually, I can do that by just having Wicd run a script to replace the /etc/network/interfaces files for each different network. I always use Wicd to set up the system for the next spot I'm traveling to, so that would work. But it seems kind of a clumsy and complicated way to work this out, to me. >> If I hit <Ctrl>+C when the boot process stalls at the configuring >> interfaces line, the remainder of the boot continues quickly, albeit >> with a failure for startpar. I haven't noticed any untoward effect on >> system behavior after doing this. >> >> Is there any downside to using <Ctrl>+C like this? > > You'll be stopping the said daemon but other than that, the boot sequence > will continue. > >> Is there a way for me to edit the /etc/network/interfaces file that will >> get rid of the problem? > > I would try first by using a fixed network configuration (ip, netmask, > gateway, dns...). If that works and speeds up the boot process, I'd start > searching for the reason of the dhcp delay. > Yeah, as I said (more clearly this time, I hope) the reason for the DHCP delay is that there isn't any DHCP server at those locations. I know I'll get a faster boot if I configure the machine's /etc/network/interfaces file for fixed IP address at each of those locations. My confusion comes from the fact that I didn't used to have to do that. I just set the interfaces file for DHCP and let Wicd handle connecting to all of the different fixed IP and DHCP sites with the proper IP address assignments. What I'm really wondering is if it's possible for me to tell my OS to make those timeouts shorter, like say 5 or 10 seconds apiece instead of 60 seconds. I'm not sure whether or not that's a bright thing to do, but I'm going to try to do research to figure it out this weekend when I have some time. Otherwise, I suppose I can just tell Wicd to swap in a different /etc/network/interfaces file for each of the networks on which I used fixed IP addresses. I hope that will work. The last time I tried using scripts from Wicd -- quite some time ago -- there were some problems with getting the scripts to run reliably. Again, Camaleón, thank you for your help! I hope you're having a nice day! Regards, Gilbert -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd8c0b7.1070...@comcast.net
