Andy Mell writes
>
> > Isn't it self-evident that these two-byte status codes are those returned
> > by wait(2) and relatives for a completed process; i.e. one byte of exit()
> > code and one byte of flags + signal number?
>
> Not really... Some of us dont program or dont have time to program, it is
> years since I programmed with unix libraries. exim needs to be usable by
> the non-programmer. I hope you are just being sarcastic.
Apologies if that came over as insulting -- it wasn't so meant. It's just
that to many of us "status 008b", "exit code 139" (after shell mutation),
etc. just induce the conditioned reflex "oh no, not another SIGSEGV!" It
sometimes seems quite rare to find a process being killed by any other
signal...
> > Of course, this doesn't get one much further without more diagnosis of the
> > failing processes. At least in John Horne's example it seems to have made
> > a "core" file somewhere (indicated by the 0x0080 bit).
>
> And what do you propose to track this problem further? Of course, it would
> be nice and easy if there was a core file for me to analyse, but there isnt.
Maybe because the process had switched uids during its life? or exec'd a setuid
program (i.e. exim)? Some Unixes suppress core files for security reasons in
such situations.
If it was reproducable, I would tell you to turn on all available exim debugging,
to locate the code area in which the SIGSEGV is happening, but it doesn't sound
as though it is.
> Running exim 1.71 under unpatched solaris 2.5 by the way. The inetd process
> died at the same time as this happened, which makes me think its an OS problem.
Indeed so! Did the inetd produce a core file (probably in /)? You could tell
from that whether it was another SIGSEGV; or from the the process accounting
files if you turn on process accounting. If processes are dying all over the
place, check /var/adm/messages (or other main syslog file) for oddities:
always supposing that your syslogd process has stayed up, of course!
Really totally unpatched Solaris 2.5? I wouldn't go around advertising that...
the Sun list of recommended and security fixes is quite long now, and there
are hackers out there, as some of us know from dire experience.
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
