On 06/16/2012 01:24 PM, Tom H wrote: > On Sat, Jun 16, 2012 at 10:42 AM, Camaleón <noela...@gmail.com> wrote: >> On Fri, 15 Jun 2012 19:56:59 -0400, Gilbert Sullivan wrote: >>> On 06/15/2012 12:58 PM, Camaleón wrote: >> >>>>> Thank you for your ideas, and I'll return to this thread when I have >>>>> any kind of information. >>>> >>>> Ok, keep us informed. I feel curious about what's going on here :-) >>>> >>> Just a note about an observation. Just for grins -- even though name >>> resolution was working fine -- I checked the contents of >>> /etc/resolv.conf. They are listed below: >>> >>> ----------------------------8<---------------------------- >>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by >>> resolvconf(8) >>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN >>> nameserver 127.0.0.1 >>> search wp.comcast.net >>> ----------------------------8<---------------------------- >>> >>> This is with the system connected at a location that does use Comcast as >>> its ISP. But the contents of this file are not at all what I'd expect. I >>> tried adding >>> >>> dns-nameservers 208.67.222.222 208.67.220.220 >>> >>> to /etc/network/interfaces. Rebooting made no difference in the contents >>> of /etc/resolv.conf. Is that because something weird is going on, or >>> because the changes in netscript that happened at the time of the update >>> have changed the way resolvconf works? I suspect the latter due to other >>> information available. >> >> If you are using the "resolvconf" package I bet you have to trust what >> the "/etc/revolv.conf" file warning says in uppercase about do not >> editing the file because is dynamically changed ;-) > > Since you have "nameserver 127.0.0.1" in "/etc/resolv.conf", I'd guess > that you have dnsmasq running and that it forwards your queries to > 208.67.222.222 and 208.67.220.220 when you specify them in > "/etc/network/interfaces". > > If you are running dnsmasq, "ps ax o cmd | grep dnsmasq" should give > you the full command that launched it as well as the file that has the > "external" dns servers (that's what I used on a new Ubuntu 12.04 > desktop install on which resolvconf and dnsmasq are installed by > default; the server's been spared dnsmasq...). > > Oh, shucks. I've changed things. Before seeing your reply I removed resolvconf. Now that I did that, the /etc/resolv.conf file looks a little more like what I'm used to seeing.
I am running dnsmasq, as it was one of aptitude's "suggested" packages (along with resolvconf) for netscript, and I installed those yesterday in hopes of resolving the problems with boot delays I figured were being caused by netscript. In case anyone is interested, the delays only happen on networks where I've set the Wicd profile to use a fixed IP address. Oddly enough, those delays look exactly like what I would expect from a system that is trying (and failing) to get a DHCP lease from a non-functioning / absent server -- two 60 sec. delays, one while configuring the interface, and the other when starting the MTA. Oddly enough, I can ping this system from another system on one of these networks (fixed IP), and the system is using the specified fixed IP address by the time it gets to the login prompt. FWIW, I tried the command you suggested and got: $ ps ax o cmd | grep dnsmasq /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new grep dnsmasq I suspect that it would have looked different if I had known to run it before I removed resolvconf. At any rate, the current contents of /etc/resolv.conf (at a location where DHCP is used) are: $ cat /etc/resolv.conf domain wp.comcast.net search wp.comcast.net nameserver 208.67.222.222 nameserver 208.67.220.220 nameserver 192.168.1.1 That's more like what I'm used to seeing. Name resolution is working much better now, but there is the unfortunate coincidence that -- while I was working on all of this -- the name resolution from the ISP was messed up, and a signal they sent my modem switched it out of bridge mode. I got that straightened out with them in a phone call this morning, but it's kind of hard to tell just which problem was doing what to my system. It's worth noting, however, that none of the other systems (that don't have virtualbox installed and which aren't using netscript) was having trouble with Internet connection or name resolution this morning. Thank you for your suggestion. I took a quick look into some man pages as a result, and it looks like I may have some interesting reading and figuring to do over the next few days. In the meantime, I'm kind of concerned that it may have been counterproductive for me to file a bug report against netscript because of the boot delays. I guess the maintainers are pretty busy these days trying to deal with bugs before the freeze. I appreciate your help in starting to get some idea of what's going on. If you have suggestions about making this more of a learning experience for me -- or if you have suggestions about what I should do about that bug report -- please let me know. I'm a little bit at sea right now. Best 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/4fdccc04.70...@comcast.net
