Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705) 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 command in. 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 hardware). 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): How reproducible: Always 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. Additional info: 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.