Bug 13636 - problem with the internal time service of inetd
Summary: problem with the internal time service of inetd
Status: CLOSED DUPLICATE of bug 11548
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: inetd   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-10 08:43 UTC by volf
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-10 08:43:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description volf 2000-07-10 08:43:40 UTC
I use the time service (in /etc/inetd.conf: time stream tcp nowait root 
internal) for simple time synchronization in small network (~10 computers) 
and after some time (about 20 days) inetd stops working (telnet, pop3, 
ftp, time). It does not reject connections, it closes them immediately. 
In /var/log/messages there is this message:

... inetd[373]: accept (for time): Too many open files

The inetd process has 1024 open files (/proc/{inetd pid}/fd) and 
netstat | grep :time 
gives long list (I suppose 1024 lines) of this kind:

tcp   1   0 {server name}:time  {client IP}:{port}     CLOSE_WAIT

I have to restart inetd to make it work, but number of open files of inetd 
process is still growing with every connection to the time service.

Client computers use Windows NT Workstation 4.0 (timesync, 
http://www.intsoft.com/products/timesync/) and one Linux (netdate).
Telnet to time port has the same effect - connection is not closed by 
server. Very old Slackware Linux did not have this problem.
Server has the kernel 2.2.16 compiled by me.

Martin Volf
qwert@egarden.cz

Comment 1 Pekka Savola 2000-07-22 21:31:55 UTC

*** This bug has been marked as a duplicate of 11548 ***


Note You need to log in before you can comment on or make changes to this bug.