Red Hat Bugzilla – Bug 138133
NTP Script takes excessive time to run on a firewall
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Description of problem:
When running ntpd on a firewall with a lot of custom rule chains, the
ntp init script takes ages to execute. This happens because of the
initial 'if iptables -L -n 2>/dev/null | grep -q RH-Firewall-1-
INPUT ; then ...' which is not bypassed by FIREWALL_MODS="no"
in /etc/sysconfig/ntp. The ntpd init script need to be modified to
not do anything with iptables at all when FIREWALL_MODS="no".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create loads of iptables rules and custom chains
2. run 'service ntpd status'
3. wait for ages for command to return
Actual Results: The script eventually comes back, but it can take a
long time on a slow machine with 6 interfaces and more than 100,000
Expected Results: You should be able to override the run of
iptables -L by setting FIREWALL_MODS="no" in /etc/sysconfig/ntp
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.
I find it a little disappointing that this buzilla has been closed with no
explanation as to why anyone would want to retain the current behaviour?? If
you are able to explain a good reason for running iptables from the ntp init
script at all when FIREWALL_MODS="no", then I will leave this bugzilla closed.
The explanation has been given internally and is only visible with a privileged
Bugzill account. It is visible to the Red Hat support staff that then
communicates the decision and it's reasons to the customers who reported the
issue. That is part of Red Hat's support and development process.
The problem now is that you reported this issue directly via Bugzilla. Bugzilla
is used as a development tool and every change has to go through it. So Red Hat
appreciates bug reports. There though is no SLA and thus customer issues need to
go through the official support department. Only there we can ensure that
decisions are reported back to the customers.
Now the planning principle for RHEL updates is to limit the rate of change as
every change bears the risk of regression. Product management decided that this
request does not satisfy the criteria for inclusion in an update at this stage
of the RHEL3 life cycle: it's impact is limited and it is possible to
work-around, while RHEL 3 as a release is already in the transition from Full
Support (which ended with Update 8) to the Maintenance Phase of it's lifecycle.
Ok, thanks for your answer.
That being said, I would say that no longer redundantly running 'iptables -L'
would be more of a fix for a fairly benign bug rather than the introduction of a
potential regression fault.
If you look in the script, it does nothing with the captured output of the
iptables list when FIREWALL_MODS="no", so putting an 'if [ !FIREWALL_MODS ==
'no' ]' conditional around the running of 'iptables -L' would be a logical solution.
I incidentally have a support contract for RHEL3, however, I chose (perhaps
erroneously), to log the bugzilla so it was in the public forum for other users
to see. It did surprise me that it took close to 2 years for anyone to respond,
as I had previously considered bugzilla an appropriate avenue to logs faults
against RedHat systems.
Such long response times, only to be followed up with a 'Closed for undisclosed
reasons' leads me to wounder about the RedHat processes around dealing with
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.