🚀 go-pugleaf

In article <806539154snz@tcs01.demon.co.uk>
           david@tcs01.demon.co.uk "David James" writes:

> I have an Interactive Systems (SVR3) Unix that I have connected to 
> an Ethernet and talking SLIP to an Internet Service Provider.
> 
> Occasionally, when there's a reasonable amount of network activity on 
> both interfaces, I'm getting messages "Socket: Out of streams resources". 
> Before I start increasing tuneable parameters more or less at random, 
> can anyone suggest which ones I should try first.

Try  netstat -m  to see which resource is running low/out.

-- 
Andrew Gabriel                        Home: Andrew@cucumber.demon.co.uk
Consultant Software Engineer          Work: Andrew.Gabriel@net-tel.co.uk

In article <806539154snz@tcs01.demon.co.uk>
           david@tcs01.demon.co.uk "David James" writes:

> I have an Interactive Systems (SVR3) Unix that I have connected to 
> an Ethernet and talking SLIP to an Internet Service Provider.
> 
> Occasionally, when there's a reasonable amount of network activity on 
> both interfaces, I'm getting messages "Socket: Out of streams resources". 
> Before I start increasing tuneable parameters more or less at random, 
> can anyone suggest which ones I should try first.

It is much more likly that you have a program which is not cleaning up
after it's self properly, so even if you increase the paramers that it
will still fail :-(.

The classic example is:
	create a steams pipe, 
	fork 
	attach the streams pipe to the stdin and out of the fork, 
        exec child process,
        do some processing, 
        kill child process (which closes the childs end of the streams pipe. 
        close the parents end of the spipe.

But because the parent did not close it's end of the streams pipe this pipe
remains in existance. Due to what I assume is a bug in the kernal these
zomby steams can remain allocated even when the parent process dies.

Also see if you have any FIN WAIT 2 states shown when using netstat -a.
I don't think that there is any way to clean theses up unless you open
the setsockopt / t_optmanagemt with SO_REUSEADDR option.
Unfortunatly the timout in the kernal does not seem to function on that
one :-(

> 
> The stune file is
> NSTREAM         48
> NQUEUE          256

My ISC machine is at a customers site so it is a bit of a pain to go and
look up my settings. But if no one else helps I'll dial in and have a
look for you.

When setting the machine up use the optin which alows you to set it for as
many users as possible. 
If you have the optional RFS module it sets "everthing louder than
everyting else" to quote the old roady saying. The one important setting
I seem to rember that is essential which was not mentioned in the manuals
that I had and used to cause problems was NQUEUE had to be 4 times larger
than NSTREAM. 

What does the command:
	netstat -m 
show you when you have theses problems?

BTW do you use the standard ISC slip software? If you do you might like
to take a look at the adialer software I uploaded onto demon a couple of
years ago as it alows you to automate the connection times (and the
softeware to run) when connectiong to Demon. I have a newer version designed 
to run with the BSD OS but need someone to test that it still works with
ISC, so if anyone reads this and would like a copy, please email me.

-- 
Regards Philip Shearer 
 
As long as mankind shall continue to bestow more liberal applause on their
destroyers than on their benefactors, the thirst of military glory will ever
be the vice of the most exalted characters.
                                        -- Edward Gibbon