Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!mntgfx!sboyle From: sboyle@mentorg.com (Sean Boyle x1542) Newsgroups: comp.sys.apollo Subject: Re: IDA Sendmail 5.65 on Domain/OS problem Keywords: IDA sendmail SR10.3 Message-ID: <1991Feb19.235255.1694@mentorg.com> Date: 19 Feb 91 23:52:55 GMT References: <368@camdev.comm.mot.com?> <1093@eba.eb.ele.tue.nl> Organization: none Lines: 29 In article <1093@eba.eb.ele.tue.nl> wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) writes: >In article <368@camdev.comm.mot.com?> mmuegel@mot.com (Michael S. Muegel) writes: >=> >=> ----- Transcript of session follows ----- >=> 451 endmailer mail: wait: No child processes >=> 554 ... Internal error > Did you set the Ox and OX to reasonable values for Apollo? There is a process limit even under 10.3 which is dependent upon your ram size... It is even possible that the getla() stuff needs a little work. I suspect that the values returned are too small to be of use. I was going to multiply the return values by 10, but ran out of time... >My problems are slightly different. ;) I'm running it on a DN4500/sr10.2, >and I seem to remember a warning that it does not have a warranty for this >combination. However this run just fine. Except: > 1) bounced mail gets returned to the original user with all '\n' > alone on a line doubled. So empty space in longer. I could live > with this. > 2) The forked child dies everytime. And a traceback will tell you that > it can't traceback the process, because it has an invallid stack. They did some clever stuff with changing the argv[0] to show you what sendmail is doing at any given time. This clobbers the stack with Apollo. I #ifdef'd it out. -- "There is a time to laugh and a time not to laugh and this is not one of them." Inspector Jacques Clouseau sboyle@mentor.com Mentor Graphics Corporation