I am running a script from internet superserver daemon.

The following entry is present in inetd.conf:

countd stream tcp nowait.1 countd /scripts/system/websys/countd.sh countd

If I try to connect to the server usint netcat, I get the following symptoms

$ nc neptune countd
COUNTD

(I wait two minutes here)

$ nc neptune countd
COUNTD

ok, so far
quickly retype:

$ nc neptune countd
$

Ok, no echo. Presumeably, I have met the instances limit.

$ nc neptune countd
$ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused

Huh, different behaviour now. This time I get an error.

If I now try this rapidly in succession (a flood?):

$ nc neptune countd
$ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused
$ nc neptune countd
$ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused
$ nc neptune countd
$ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused

(I wait two minutes here)

$ nc neptune countd
$ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused

I can't connect to the server any more.

$ netstat -a|grep "countd"
$

The listening port has some how closed. I have to stop and restart the internet
superserver daemon.

Why do I get no echo at one invocation, then an error on a subsequent 
invocation?

Why has the listening port remained closed for so long?

It appeared to have reopened again after a further few minutes.

Regards,

Mark.

-- 
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Telephone: (0121) 247 1596
International: 0044 121 247 1596

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

"Mark Hobley" <markhobley@hotpop.deletethisbit.com> wrote in message 
news:hcu893-kko.ln1@neptune.markhobley.yi.org...

> countd stream tcp nowait.1 countd /scripts/system/websys/countd.sh countd
>
> If I try to connect to the server usint netcat, I get the following 
> symptoms
>
> $ nc neptune countd
> COUNTD

    What is 'countd.sh's behavior? Just it just send data and terminate 
immediately? Perhaps it's getting stuck and continuing to count as an 
instance even after you think it's finished.

    DS

In alt.comp.os.linux David Schwartz <davids@webmaster.com> wrote:

>    What is 'countd.sh's behavior? Just it just send data and terminate 
> immediately? Perhaps it's getting stuck and continuing to count as an 
> instance even after you think it's finished.

I've retested with the following, and get the same symptoms:

#!/bin/sh
echo COUNTD

Regards,

Mark.

-- 
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Telephone: (0121) 247 1596
International: 0044 121 247 1596

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

[Of the newsgroups the OP specified, only comp.unix.programmer exists
on my server.]

In article <hcu893-kko.ln1@neptune.markhobley.yi.org>, markhobley@hotpop.deletethisbit.com (Mark Hobley) writes:
> I am running a script from internet superserver daemon.
> 
> The following entry is present in inetd.conf:
> 
> countd stream tcp nowait.1 countd /scripts/system/websys/countd.sh countd
> 
> If I try to connect to the server usint netcat, I get the following symptoms
> 
> $ nc neptune countd
> COUNTD
> 
> (I wait two minutes here)
> 
> $ nc neptune countd
> COUNTD
> 
> ok, so far
> quickly retype:
> 
> $ nc neptune countd
> $
> 
> Ok, no echo. Presumeably, I have met the instances limit.

Yes, but note that the connection succeeded, then was closed
without the server sending any data.

> $ nc neptune countd
> $ neptune.markhobley.yi.org [10.0.0.8] 4001 (countd) : Connection refused
> 
> Huh, different behaviour now. This time I get an error.

Because now inetd has closed the listening socket.

> Why do I get no echo at one invocation, then an error on a subsequent 
> invocation?

Because there's a race between your client and inetd closing the
listening socket.  Until inetd decides that the limit has been
reached and closes the socket, it remains in LISTEN state and the
client can connect.  However, if inetd never accepts the slave
socket, or accepts and then closes immediately, your client will
see a successful connection followed by a close.  (That close could
be either a FIN or an RST, depending on what exactly inetd and the
client do.)

>From the client's point of view, the server can be in one of three
states:

- Listening and responsive.  This 

> Why has the listening port remained closed for so long?
> 
> It appeared to have reopened again after a further few minutes.

Apparently it takes inetd a while to decide to create a new listening
socket.  I don't know whether that's by design or accident.  You
could consult the inetd documentation or source (if the latter is
available, which I assume it is, since you seem to be using Linux).

This looks a bit like the 2MSL wait for TIME_WAIT, but presumably
inetd is using SO_REUSEADDR, so you shouldn't be hitting that.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

Cooperation is just like two pagodas, one hardware and one software.
 -- Wen Jiabao