Description of problem: Squid requires a restart, after logging-in and network manager connecting over wireless, to operate correctly. Version-Release number of selected component (if applicable): 3.0.STABLE6-1 How reproducible: Steps to Reproduce: 1. Reboot PC 2. Login in 3. Wait for Network Manager to connect 4. Try to access a page on the internet (firefox sits there waiting) 5. Restart Squid 6. Try to access a page on the internet (success) Actual results: Unable to access internet Expected results: Access to internet Additional info: I am new to the bug reporting process. But am happy, possibly with guidance, to provide more info.
Firefox shows following: While trying to retrieve the URL: bugzilla.redhat.com:443 The following error was encountered: Unable to determine IP address from host name for The dnsserver returned: Timeout This means that: The cache was not able to resolve the hostname presented in the URL. Check if the address is correct. Your cache administrator is root.
I see the same problem with squid-3.0.STABLE7-1.fc9.x86_64 on a wired network. I reboot, log in, and squid doesn't respond. I restart squid and it works fine. I tried moving squid later in the startup sequence (from /etc/rc.d/rc5.d/S90squid to /etc/rc.d/rc5.d/S98squid) but that didn't help.
The problem is that squid uses resolv.conf to load nameservers by default and the NetworkManager re-create resolv.conf during each starting. The clearest way to fix the problem is to use dns_nameservers option in the squid.conf file and to put there servers that are in the resolv.conf file. This is not a bug of squid because the squid can't affect resolv.conf creation and the one provides resources to fix the problem. These findings could be read from /var/log/squid/cache.log file.
*** Bug 500075 has been marked as a duplicate of this bug. ***
Ok, I have same issue Bug 500075 (and thank you for answer in it). It really seams as empty resolv.conf on momen squid start, log says about it next: 2009/04/28 01:14:18| Warning: Could not find any nameservers. Trying to use localhost 2009/04/28 01:14:18| Please check your /etc/resolv.conf file 2009/04/28 01:14:18| or use the 'dns_nameservers' option in squid.conf. And I'm not very familar with upstart, but may be me can tell what squid MUST be started after NetworkManager? On my glance it is BUG in any case, but may be not of squid though.
My recommendation is to NOT use NetworkManager on servers such as Squid. Instead use the "static" network configuration set in /etc/sysconfig/network-scripts/... these are capable of configuring most network setups including wireless. The problem with NetworkManager is that it is user driven and very dynamic, which in many cases means Squid won't be able to run until a user logs on to the console, and even if NetworkManager is set to enable some network by default users can easily distupt this by just logging in..
(In reply to comment #6) > My recommendation is to NOT use NetworkManager on servers such as Squid. > Instead use the "static" network configuration set in > /etc/sysconfig/network-scripts/... these are capable of configuring most > network setups including wireless. I forgot say in my case it is standard wired lan connection, not WiFi. And I agree, what static interface configuration may solve problem but, in any case, it is only workaround, which does not solve problem itself. > The problem with NetworkManager is that it is user driven and very dynamic, > which in many cases means Squid won't be able to run until a user logs on to > the console, and even if NetworkManager is set to enable some network by > default users can easily distupt this by just logging in.. Futhermore, may say what it is default installation of Fedora 10. And NetworkManager DO NOT used to setup connection, it is just start bu default. I think we even don't try in squid handle any user network settings on the fly, but start and work after system restart it MUST. I also may note what network function properly just after login - no any steeps needed. May be we need file bug on NetworkManager to its behavior concerned /etc/resolv.conf recretion when it is not needed? I even can't imaginate for what may be needed empty it (it is not altered, it is empty according to squid log).
Squid (and many other network servers) requires networking to be properly configured when started. This can not be guaranteed when using NetworkManager to automatically manage the network connection even if it automatically brings up Ethernet interfaces on boot. This due to NetworkManager being partially asyncronous, with no clear indication to the init scripts when the network has been initialized. For Ethernet interfaces the fix is as simple as starting system-config-network and unchecking the "Controlled by NetworkManager" checkbox on the interface(s) in question. This will prevent NetworkManager from messing with the interfaces. But I agree it's partially a NetworkManager misfeature. When the system boots it brings up the Ethernet interfaces (/etc/init.d/network), which then get reconfigured again when NetworkManager starts, including clearing /etc/resolv.conf. It would be good if it took over the interfaces and /etc/resolv.conf as-is without reconfiguring them from scratch..
(In reply to comment #8) > Squid (and many other network servers) requires networking to be properly > configured when started. This can not be guaranteed when using NetworkManager > to automatically manage the network connection even if it automatically brings > up Ethernet interfaces on boot. This due to NetworkManager being partially > asyncronous, with no clear indication to the init scripts when the network has > been initialized. There is a clear indication: NetworkManager (man NetworkManager) will execute scripts in /etc/NetworkManager/dispatcher.d on network events. The apps/services need to stop being stupid. Network isn't always up. They need to either handle network state themselves internally, or be restarted when the network goes up or down. So putting a dispatcher script in /etc/NetworkManager/dispatcher.d for squid that simply restarts squid when an interface goes up or down should be sufficient for you here. That script should ship with the squid package. Again, 'man NetworkManager' will tell you absolutely everything you need to know for a dispatcher script, and you can find examples there already installed by initscripts. initscripts even installs a 00-netreport dispatcher that will notify programs that have requested information on network changes that something has occurred. Maybe squid should use that instead. > For Ethernet interfaces the fix is as simple as starting system-config-network > and unchecking the "Controlled by NetworkManager" checkbox on the interface(s) > in question. This will prevent NetworkManager from messing with the interfaces. Again, that's not the solution. The solution is to fix the services to be responsive to *all* situations including situations where networking is sometimes transient. That implies restarting the services when the network is up. Or, you could try NETWORKWAIT=yes in /etc/sysconfig/network which will force bootup to block until a network interface is up, or a timeout has occurred. > But I agree it's partially a NetworkManager misfeature. When the system boots > it brings up the Ethernet interfaces (/etc/init.d/network), which then get > reconfigured again when NetworkManager starts, including clearing > /etc/resolv.conf. It would be good if it took over the interfaces and > /etc/resolv.conf as-is without reconfiguring them from scratch.. The normal network service shouldn't be turned on in default installs. If you've turned it on yourself, then of course NM and the network service will both try to do the same thing. So we need to figure out why its clearing resolv.conf. Have you put DNS1/DNS2/DNS3 into your /etc/sysconfig/network-scripts/ifcfg-eth0 file like the blank resolv.conf may have told you about? resolv.conf is *transient* and changes depending on what connections are brought up (even if NetworkManager is not turned on!!); just using 'ifup eth0' if eth0 uses DHCP will clear your resolv.conf. Thus, for your static IP connections, there needs to be some canonical location for the DNS servers and search domains, and that canonical location is the ifcfg file for that interface.
I tried with a clean F11-Preview network install as of yesterday. Both NetworkManager and network is on by default from what I can tell. Did not make any network configuration at all, left all at the default. Only manual configuration done after the install was: yum install squid chkconfig squid on reboot. Squid starts very very late in the bootup, long after both network and NetworkManager. network sets up eth0 properly using DHCP, which populates /etc/resolv.conf. NetworkManager service starts a little later, but bootup by default does not wait for it to finish configuring the interfaces. When Squid starts shortly after NetworkManager /etc/resolv.conf is empty. Running system-config-network and configuring eth0 to not be controlled by NetworkManager "cures" the problem. But I see your point about adding NetworkManager integration to the Squid package. I'll try to allocate some time for that in next package maintenance cycle in a few days.
(In reply to comment #10) > I tried with a clean F11-Preview network install as of yesterday. Both > NetworkManager and network is on by default from what I can tell. Did not make > any network configuration at all, left all at the default. Only manual > configuration done after the install was: Hmm. We turned 'service network' off by default in F-10. I wonder how that's back on now. It shouldn't be.
I wonder... "service network" is on in my F10 installs as well.. and don't remember turning it on manually.
Added a NetworkManager dispatcher for Squid in 3.0.STABLE15-2
squid-3.0.STABLE15-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/squid-3.0.STABLE15-2.fc11
squid-3.0.STABLE15-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/squid-3.0.STABLE15-2.fc10
squid-3.0.STABLE15-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/squid-3.0.STABLE15-2.fc9
squid-3.0.STABLE15-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update squid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-5380
squid-3.0.STABLE15-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update squid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5354
squid-3.0.STABLE15-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update squid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5464
It helps. Henrik Nordström, good job, thank you very much!
squid-3.0.STABLE15-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.0.STABLE15-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.0.STABLE15-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I'm change summary to exclude "wireless" word, as problem appeared widely. Thank you again to resolve it.