HP3000-L Archives

July 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Mon, 24 Jul 2000 16:49:10 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
I've got a problem on a 6.0 system where INETD is being used for telnet,
Samba, and FTP.  Every so often (days/weeks) Samba and FTP connections stop
working.  Restarting the JINETD job seems to clear up the problem.

For FTP, the symptoms are that the client connection is immediately dropped
after connecting (before the login prompt is issued).  The JINETD job
$STDLIST shows that the call for FTP came in, and the access time for
FTPSRVR.ARPA.SYS get updated.  There are no errors on the console or in the
$STDLIST.

I note that if you run FTPSRVR.ARPA.SYS it normally just exists quietly
(it's apparently expecting a socket number or something equivalent via
parm/info), so one possibility is that INETD has gotten confused and is no
longer passing this information correctly.

For Samba, the call request is again displayed in the JINETD $STDLIST, and
one or more of the following messages print on the system console:

** NETIPC Internal error: Error reported from PM (1617)

The "1617" happens to match the job number of the INETD job.

As far as we can tell, both the FTP and Samba services quit working at the
same time, which rather points the finger at INETD.  Telnet keeps working,
but that's not too surprising since most of the telnet implementation is all
special case code and doesn't pass through the normal INETD code path.

About the only unusual thing about the machine with the problem is that it
has two 10Mb LAN interfaces on two different subnets.

I've got the feeling that I've seen something similar to this in the past,
but don't recall ever finding a permanent solution (other than just
restarting it each time it fails).

G.

ATOM RSS1 RSS2