[Christian Tismer]

The reason turned out to be dependent wether Python 1.5 (the early version, of course) was made with threads or not. The threaded version had a bad effect on sys.stdin after an os.fork(). sys.stdin was a "bad file number" in the child process. Maybe these are known things, but there are some issues: [...] To the Mailmen: It was quite hard to track this error down through the mailman scripts. Finally, I ended up if I made the deliver fork temporarily into a do-nothing. The "deliver" script does a number of forks. I does no proper checking if the forks work (under Linux, btw., fork never returns ENOMEM, so the check isn't safe yet).

I don't understand -- "forker(tries)" in the "deliver" script tries fork()ing, catches any exceptions raised, and re-raises them if a) the error causing the exception weren't EAGAIN or b) this were failed fork() number "tries"+1.

Catching the exception is about as far as you can go to "check if the forks work", IMHO -- when fork() stops working, there usually aren't very many clever things worth doing (short of giving up), are there?

Deliverer.py also trusts the os.popen very much.

Well, os.popen() should bail out by raising os.error whenever it's behaving "untrustworthy", shouldn't it?

Anyway, sys.stdin is read without error checking in the deliver script. I think, some more checks are necessary to guarantee that failing deliveries get noticed.

I don't think I have understood enough of the problem to fix this properly, so any suggestions on exactly _what_ those extra checks should check for would be nice :)

-- Harald