But my questions would start with, what does lsof say? Can you run the code on another machine which is not a test kernel, what does that do? (2.4.0 has a new VM, you may have hit a bad case for it. If you don't have another machine but are willing to post, you should be able to find someone who will run the experiment for you.) How much stack are you eating up?

But while I don't have any suggestions for your problem, I have an unrelated suggestion. You should not be calling srand, Perl does that for you and has for several versions now. It is actually counterproductive to call it again. (On Linux you will be exhausting your system's entropy.)

1. The EAGAIN message is consistent with a write to an unavailable, non-blocking socket. It might have been placed into a non-blocking state before a connect call was issued and the script might be attempting to write to it before that connection was actually established. If the socket can't be written to yet, and you attempt to write to it, expect an EAGAIN "error" upon your write. This might just be due to a poor implementation of non-blocking IO.
2. Instead of doing for (;;) { }, just sleep for a while. What you're basically doing is putting your script in a rather tight infinite loop, which will effectively hold your CPU usage at 100%. Most Unix kernels kind of figure that it's not doing anything productive and lower the priority of the process accordingly, so you might not notice any effects on other processes, but it would help diagnose the problem if your script was sleeping idly instead of working in a tight loop there. One less bit of activity on your system that might be catalyzing a separate problem.

• the compile-time RAM limitation
• the so-called "soft" limitation
• the hard limitation
• the physical limitation

Also, it looks to me like your program could benefit from threads if dacts() is forking off Napster clients. Unfortunately, threads are in pretty poor shape in Perl. Click here to see why. A C program with an embedded Perl interpreter might help you initialize and get you ready to run but the threads would heavily cut down on memory usage by those clients. If dacts() does not fork than you are confused because you use terms like "threaded" and "spawn" and thus make this paragraph null. Though, as tilly mentions, no one can imagine what dacts() does, if your system is coming to a halt, then I imagine that a large amount of processes are being forked. Another thing to ask yourself, also, is: Do I need so many Napster clients?

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

By Popular Request, the dacts() function:

sub dacts
{
  my ($un, $pwd, $srvr, $port) = @_;
  my $r; my $n;

  warn qq-attempting $srvr:$port- if $DEBUG;
  $r = $n = MP3::Napster -> new ( qq-$srvr:$port- );
  if ($r) { warn qq-connected to server\n- if $DEBUG } else { warn qq-
+never connected to $srvr:$port- ; return }

  warn qq-username: $un | password: $pwd-;

  $n -> my_login ( $un, $pwd, qq-ralphnap-, LINK_UNKNOWN, 8899 );
    if (!$n) { warn qq-could not log in to server $srvr : $! \n $@- ; 
+return }

  warn qq-logged in okay...\n- if $DEBUG;
  return $n;
  1
}
[download]

and, while i appreciate it, AgentM, I of course ran it with one instance, and it works. It is working fine as I write this, with 60 connections up (and netscape and an opennap server and zillions of rxvt's. When I say that it doesnt fork(), I mean that one process is running. It is my understanding from perldoc -f fork ...

Does a fork(2) system call to create a new process running the
same program at the same point.  It returns the child pid to the
parent process, C<0> to the child process, or C<undef> if the fork is
unsuccessful.  File descriptors (and sometimes locks on those descript
+ors)
[download]

actually spawns a new process. The amount of memory actually used in this case is pretty slim compared to what most would expect:

MemTotal:       189248 kB
MemFree:          7540 kB
SwapTotal:      393156 kB
SwapFree:       380144 kB
[download]

So I think I have concluded here that memory is not the issue, unless something else is coming up that I'm missing.

--
i am not cool enough to have a signature.

You are running out of handles somewhere. Since 65 is really close to a magic number (2**6 == 64) I'd bet that all those connections to the network are hitting a limit.

--
$you = new YOU;
honk() if $you->love(perl)

Hi, all. I just wanted to follow up on this post since it seemed to have a few people (or at least me) stumped. Well, I had to reboot the system for some maintenance, and I was then able to open over 2,000 connections with a modest 40MB of RAM. Clearly whatever the problem was, it was a software issue that was eluding me. All is well now. :)

thanks to all who responded.
dep

--
i am not cool enough to have a signature.