Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 453304

Summary: Squid requires restart after Network Manager made connection to network
Product: [Fedora] Fedora Reporter: Trevor Green <trevor>
Component: squidAssignee: Henrik Nordström <henrik>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: dcbw, dmk, henrik, jonathansteffan, jskala, pahan
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 3.0.STABLE15-2.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-16 01:58:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Trevor Green 2008-06-29 10:23:12 UTC
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.

Comment 1 Trevor Green 2008-06-30 10:04:31 UTC
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. 

Comment 2 David Keaton 2008-07-29 05:17:04 UTC
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.

Comment 3 Jiri Skala 2008-10-03 09:31:00 UTC
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.

Comment 4 Pavel Alexeev 2009-05-11 18:25:24 UTC
*** Bug 500075 has been marked as a duplicate of this bug. ***

Comment 5 Pavel Alexeev 2009-05-11 18:32:52 UTC
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.

Comment 6 Henrik Nordström 2009-05-11 22:44:59 UTC
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..

Comment 7 Pavel Alexeev 2009-05-12 03:46:30 UTC
(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).

Comment 8 Henrik Nordström 2009-05-12 22:29:06 UTC
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..

Comment 9 Dan Williams 2009-05-13 14:32:54 UTC
(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.

Comment 10 Henrik Nordström 2009-05-13 18:01:14 UTC
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.

Comment 11 Dan Williams 2009-05-14 18:29:38 UTC
(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.

Comment 12 Henrik Nordström 2009-05-14 21:52:32 UTC
I wonder... "service network" is on in my F10 installs as well.. and don't remember turning it on manually.

Comment 13 Henrik Nordström 2009-05-23 11:40:11 UTC
Added a NetworkManager dispatcher for Squid in 3.0.STABLE15-2

Comment 14 Fedora Update System 2009-05-23 12:34:36 UTC
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

Comment 15 Fedora Update System 2009-05-23 12:35:21 UTC
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

Comment 16 Fedora Update System 2009-05-23 12:36:11 UTC
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

Comment 17 Fedora Update System 2009-05-25 21:07:39 UTC
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

Comment 18 Fedora Update System 2009-05-25 21:11:31 UTC
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

Comment 19 Fedora Update System 2009-05-25 21:15:07 UTC
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

Comment 20 Pavel Alexeev 2009-06-10 12:05:54 UTC
It helps. Henrik Nordström, good job, thank you very much!

Comment 21 Fedora Update System 2009-06-16 01:58:10 UTC
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.

Comment 22 Fedora Update System 2009-06-16 02:21:47 UTC
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.

Comment 23 Fedora Update System 2009-06-16 02:41:34 UTC
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.

Comment 24 Pavel Alexeev 2009-06-16 20:22:35 UTC
I'm change summary to exclude "wireless" word, as problem appeared widely.

Thank you again to resolve it.