Subject: lost processes with mtest and ssl failures

From: ber <[email-masked]>
Date: Sat, 2 Nov 2002 02:22:21 -0500

On Mac OS X 10.2.x I built imap-2002.RC7 with SSL pointing to the 
preinstalled sll and crypto libraries in /usr/lib.

When I run mtest and get a failed ssl negotiation (?TLS/SSL failure for 
mail.mac.com: SSL negotiation failed) my
user process limit is decremented by one.  The failure isn't an issue.  
That happens a lot with mac.com.  The fact
that each failed negotiation decreases the number of processes I can 
create is what I'm asking about.

I sent a mail to the darwin-developers list to find out why the system 
reduces the effective process limit.

The question for c-client is why mtest might be consuming and not 
freeing a process slot when it fails an
SSL negotiation.  Is it that the mtest program being a test program is 
not cleaning up some resource that
I should be cleaning up in my real client?  I have the same problem in 
the client I'm writing but thankfully
could reproduce it in mtest.

Or does this problem sound weird?  Mark, I read all the doc files, 
really.

Here's what the mtest run looks like:

[late:~/Developer/src/imap-2002.RC7] ber% mtest/mtest
MTest -- C client test program
warning: this program uses gets(), which is unsafe.
Personal name: ber
Debug protocol (y/n)?y
Mailbox ('?' for help): {mail.mac.com/imap/user=foobar}
[Trying IP address [204.179.120.64]]
* OK Netscape Messaging Multiplexor ready
[Netscape Messaging Multiplexor ready]
00000000 CAPABILITY
* CAPABILITY STARTTLS IMAP4 IMAP4rev1 LITERAL+ AUTH=LOGIN AUTH=PLAIN 
AUTH=EXTERNAL STARTTLS
00000000 OK CAPABILITY completed
00000001 STARTTLS
00000001 OK STARTTLS completed
?TLS/SSL failure for mail.mac.com: SSL negotiation failed
Mailbox ('?' for help):
Sat, 2 Nov 2002 02:15:41 -0500 (EST)

Before this was run I could fork 79 processes with my fork test.  After 
it, 78.   Each time there's a failed negotiation I can fork one
fewer process with my fork test program.  This version of OS X has a 
per user process limit of 100.  Eventually all my slots are
used up and no programs run (EAGAIN).  The processes are not shown in 
ps as zombies or otherwise.

Thanks,

	brian

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sat, 2 Nov 2002 09:34:07 -0800 (PST)

If you are losing processes and they are not showing up as zombies, this
sounds like a bug in Mac OS.  NeXTSTEP also tended to collect such things; my
NeXT here currently has 138 "<mach-task>" processes, all with a process id of
-1; they're not zombies, they're something else.

If using the /norsh switch in the mailbox name stops these from happening,
that would suggest that Mac OS isn't doing process inheritance properly.  The
rsh code forks a child and pipes its stdio.  The child in tun immediately
forks a grandchild, gives its stdio to the grandchild, and terminates.  The
parent reaps the child, the grandchild is inherited by init, and what's left
are the parent and grandchild.  When the grandchild terminates, it is reaped
by init.

At least, that's the way it works on functional UNIX systems.  What Mac OS
chooses to do is another matter.

This sounds like something you may want to discuss with Apple.  This *is* an
operating system issue.  No matter what the application does, the operating
system should not just "lose" processes.  Applications may spawn zombies, but
it should always be possible to determine that there are zombies and what
running application is failing to reap them.  Disowned processes are supposed
to be inherited by init and reaped when they terminate.  If Apple wants to
play in the UNIX market, they need to have a functional UNIX.

---

From: ber <[email-masked]>
Date: Sat, 2 Nov 2002 15:19:49 -0500

I knew I could count on you.  Using /norsh does not exhibit the problem.
That's the workaround I was hoping for.  Thanks.

Agreed, this is an OS issue and I've sent mail to the OS dev list
(darwin-developers) and filed reports at Apple's bug site.  If and when 
I
get a response other than "understood" I'll try to produce a trivial 
example
per your description.

Thanks,

	brian