RE: How limits are enforced (was: various maxproc limits)
RE: How limits are enforced (was: various maxproc limits)
- Subject: RE: How limits are enforced (was: various maxproc limits)
- From: "Yefim Somin" <email@hidden>
- Date: Thu, 6 Oct 2005 13:01:38 -0400
RE: driving the load on Mac remotely.
Leaving the limit of 128 pty's alone for now, I have found that trying to
drive just one scripted load through a telnet connection may work for a
short sequence but is very flaky. The tool I am using (RTE freeware for
which I have source) opens a telnet connection and then sends a sequence of
strings taken from a script file in response to patterns received from the
target system, e.g.:
~Rin: ~Sadministrator~T0-0
~Rrd:~S<password>~T0-0
~Rtor$ ~Sls~T0-0
~Rtor$ ~Sexit~T0-0
~DONE
Here ~R is followed by the expected pattern, ~S is followed by the string to
send in response, ~T is followed by the designated delay in seconds. The
above script logs in, does "ls" command and exits. ~R parts describe tails
of the appropriate prompts.
I have tried the above sequence repeatedly on several Mac machines from
different sending platforms with varying delay values, and it works about
half of the time with the other half just getting stuck somewhere in the
middle. It always works when the target is some other platform (Unix
flavors, Windows, etc.). Is there something I could do to investigate it
further or is it a case for submitting a bug?
Best regards,
Yefim
> Not directly related to my questions, but painful nevertheless, is
> the fact
> that my mechanism of connecting and funneling commands to my Mac
> system has
> deteriorated since yesterday (it's RTE - remote terminal emulation
> software
> which telnets to the remote node and sends a sequence of characters
> across
> the connection in response to appropriate prompt patterns from the
> remote
> system). Currently, unlike the day before, it sends enough to
> provide ID and
> password and login, but then the communication is broken (I suspect
> the
> prompt patterns don't get delivered properly). I am describing it
> on the off
> chance that this may be something obvious. (I should mention that I
> am new
> to Mac and also that that same procedure still works fine for other
> platforms; I can successfully telnet manually)
I have no idea. It may be that the connections are in raw mode, or
it may be that the slave side has not been properly dropped and you
are still running things in the background which are ignoring SIGHUP,
or your test program expects SystemV instead of BSD signal behaviour
with regards to the controlling tty when it's not explicitly set via
setsid() (i.e. your test process expects a HUP, but is instead in a
loop reading 0 bytes over and over instead of exiting when it sees a
0 length read in a BSD-like fashion), or any of a dozen other things.
It could just be that your RTE is on a platform that doesn't properly
perform a socket shutdown because it's sockets implementation is in
user space, and you are effectively staging a DOS attack against the
machine by virtue of not shutting down the connections properly (i.e.
if you did a netstat, you might see a lot of socket connections
sitting in FIN-WAIT-2 state because the other side reset the
connection istead of sending the final FIN because the connections in
user space are not properly resource tracked - Windows had this
problem with their WINSOCK2 implementation for some client programs,
or when the client machine crashed, for a long time; so have other
platforms).
The best way to deal with this is if you could provide a cut-down
minimal set of code that reproduces the issue, and then file a bug
including reproduction instructions. This is not a problem which
would be likely to be routed to me in any case, since it sounds like
a user space problem.
If a "netstat -a" does show a bunch of FIN-WAIT-2 state connections,
you can reduce the timer via sysctl, set socket keepalives, or do
what Apache did or the problem, and modify telnetd.
Again, telnetd is probably not the best benchmark approach.
> Best regards,
> Yefim
>
> P.S. While I was writing this, an email from you came in which the
> limit on
> the number of ptys (128) is mentioned. Could this be the limit I am
> running
> into, and if yes, can this be bumped?
It shouldn't be, unless one of the other potential problems with the
software being run and listed above is being exercised and keeping
the pty's busy or you are trying for more than ~128 simultaneous
connections. As long as you don't have that many connections, you
will be fine.
Right now, the number of pty's can't be bumped above 128. Taking the
tty line discipline approach or adding an alternate pty driver (just
copying the code in bsd/kern/tty_pty.c and renaming everything would
get you another 128, but you'd need to teach telnetd about the new
names) could raise the limit for you (the line discipline approach
would raise it to the connection limits, which are effectively the
open file limits).
Since programming things like that are what this list is supposed to
be about, someone here could probably help you with that, if you
wanted to grab the kernel sources off of opendarwin.org. 8-).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden