From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
Description of problem:
have the following line in a config file in the xinetd.d directory:
access_times = 04:00-08:00
When I restart the xinetd daemon in the messages log I get the
error "incorrect time interval [line=16]". Line 16 is the line that has that
The server says it's started but no connections are ever allowed as they get a
time refused error.
What concerns me is any server isn't completely up2date runs this line fine,
those that are completely up2date it gives this error (servers using same
According to the xinetd docs I'm using it correctly and I have tried other
ways such as "access_times = 4:00-8:00" or "04:00 - 08:00"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. add line "access_times = 04:00-08:00" to a xinetd config file
2. restart xinetd service "service xinetd restart"
3. try connecting to that service anytime (including between 4am-8am)
Actual Results: client connection refused with a time refused error.
Expected Results: Clients should be able to connect between 4-8am. I tried
setting the option to 00:01-23:59 and still was never able to connect. If I
comment out this line it works fine.
This was used in particular with a rsync service where I only allow mirror
hosts to connect between certain times (slow periods) so it does not affect my
networks during busy hours.
As for severity it's important to have this control for times, yet it's not
really a security issue (just performance) so I rated it as severity:normal.
I had RH 7.2 and did not have this problem but when I upgraded to 7.3 it
stopped letting me set the access_times setting. I should point out the
upgrade was a complete fresh install of 7.3 onto identical hardware and only
data files were moved and config files were re-created.
I wasn't able to reproduce this with xinetd-2.3.11-1.7x
What version of xinetd are you having trouble with? Does upgrading to the
latest errata version (2.3.11-1.7x) make the problem go away?
I haven't tried this since I first reported this back in Oct of last year and
have up2date has made many updates on this server since then (not sure on
xinetd itself but I for sure know kernels have been).
Tried it now and it worked fine so it must of been an older version of
something causing the bug but appears to be gone now.
Closing out old bugs. Looks like 2.3.11-1.7x fixed this one.