Matt Shade wrote:
>
> Hi folks,
>
> Has anyone gotten Sendmail/iX to work with 6.5?
Yes, people are using it successfully on 6.5.
> I recently updated my 5.5 box to 6.5, and the only thing I have a problem
> with is Sendmail, which happens to have been where my HP3000-L mail goes to.
> ( checked the archives, but no answers there)
You're one of the few people *receiving* e-mail with Sendmail/iX then. Most
people are only using it to send e-mail from their e3000s.
>
> Console messages like this appear when new mail arrives:
> Dec 26 13:32:03 localhost sendmail[589922]: NOQUEUE:
> SYSERR(SERVER.SENDMAIL): SMTP-MAIL: died on signal 0
>
> I started /SENDMAIL/PUB/DAEMON with the debug parameters, and in all the
> thousands of lines, I'll see messages like this:
> **** Data memory protection trap (TRAPS 68). ABORT: SENDMAIL.PUB.SENDMAIL NM
> PROG 14c.00074170 buildfname+$30 --- 451 SMTP-MAIL: died on signal 0
>
> Does this mean anything to anyone? Mark?
Sounds like a known bug. See below.
> I've removed Sendmail/iX and reinstalled it, and I'm pretty much patched
> with the latest. I saw Mark had asked for people who are trying Sendmail on
> 6.5, so here I am. (Mark, you probably have access to this machine....I can
> tell you how).
IIRC, my call for 6.5 users of Sendmail/iX was to learn more about a System
Abort 700 or 773 problem caused by Sendmail/iX doing setsockopt(SO_KEEPALIVE)
on a call socket. This problem (SR 8606151861) has been fixed by 6.5 beta
patch NSTFDX5A.
Before this patch was created, I built a special 6.5 version of Sendmail/iX
that omits the killer SO_KEEPALIVE call. If for some reason you're not willing
to install a beta patch, contact me for the special Sendmail/iX version.
But getting back to Matt's problem, the remainder of this e-mail message is a
cut/paste that describes in detail what's happening, and my current lack of
plans for fixing it.
-----BEGIN CUT/PASTE-----
A user of Sendmail/iX wrote:
> :run sh.hpbin.sys;info="/SENDMAIL/PUB/DAEMON"
>
> **** Data memory protection trap (TRAPS 68). ABORT: SENDMAIL.PUB.SENDMAIL
> PC=2f1.00074170 buildfname+$30
> NM* 0) SP=41847b40 RP=2f1.00067a70 recipient+$8e0
> NM 1) SP=41847ac0 RP=2f1.0006e658 smtp+$1488
> NM 2) SP=41847800 RP=2f1.0005020c $CODE$+$2e24
> NM 3) SP=41846740 RP=2f1.0009d00c _start+$bc
> NM 4) SP=41844fc0 RP=2f1.00036bb4 $START$+$1c
> NM 5) SP=41843e40 RP=2f1.00000000
> (end of NM stack)
Hmmm...
Looks like you've found a bug in the port. Nobody has ever reported this
problem to me before. :-(
It appears to be barfing because it's trying to interpret data pointed to by
the pw_gecos pointer described in /usr/include/pwd.h as being UNITIALIZED on
MPE. I'm just shocked I tell you, shocked, that uninitialized data would cause
this abort. ;-)
During the port, I was aware of a pw_gecos problem that I solved by building
sendmail with -DMATCHGECOS=0 to suppress the code that did that reference.
Looks like there are additional pw_gecos references that have nothing to do
with MATCHGECOS.
The source needs to be scanned and all references to pw_gecos need some #ifdef
MPE or somesuch to come up with an alternative solution that doesn't try to
reference this uninitialized pointer.
Unfortunately I have no personal time available to work on sendmail. If I did,
I would probably download the latest & greatest version (8.11.0) and completely
re-port it to MPE. My current 8.9.1 port is starting to show its age.
If you or somebody else wants to fix this bug in 8.9.1, I will happily rebuild
8.9.1 with your fixed code.
I suspect the reason why this hasn't surfaced before is that most users of
Sendmail/iX are probably using it to send mail out to other machines, not to
receive mail on MPE.
--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...
|
