On Mon, 30 Apr 2001, Juha Saarinen wrote:
> Nope, will try that. The port fetches Exim from one of these sites:
>
> ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/ \
That site ceased to be the primary FTP site about 18 months ago. Only
last week I finally removed everything from it. The new FTP site is
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/
> And this is the only patch applied, as far as I can tell:
None of the points listed appear to apply to the base distribution.
> su-2.05# /usr/local/sbin/exim -d9 -q30m
> Exim version 3.22 debug level 9 uid=0 gid=0
> probably Berkeley DB version 1.8x (native mode)
> Actual local interface address is 192.168.0.239 (xl0)
> Actual local interface address is 127.0.0.1 (lo0)
> Caller is an admin user
> Caller is a trusted user
> originator: uid=0 gid=0 login=root name=Charlie Root
> pid written to /var/run/exim.pid-q30m
> LOG: 0 MAIN
> exim 3.22 daemon started: pid=9148, -q30m, not listening for SMTP
> set_process_info: 9148 daemon: -q30m, not listening
> daemon running with uid=0 gid=0 euid=0 egid=0
> SIGALRM received
> 1 queue-runner process running
> Starting queue-runner: pid 9149
> LOG: 0 MAIN
> Start queue run: pid=9149
> queue running main directory
> LOG: 0 MAIN
> End queue run: pid=9149
> Segmentation fault
... so it died after completing a queue run. (And I presume it's the
daemon that died, not just the queue runner?) That suggests that the
problem might be in the code for reaping completed processes.
Wait a minute. Exim doesn't reap completed processes until it wakes up
for some other reason. So, the question is: was process 9148 still
running after this test, or not? I rather suspect not, because after a
queue runner has logged "End queue run", all it does is exit. Hmm.
Unless it crashed while trying to write the log? Was that message "End
queue run" actually written to the log?
You may have to insert some debug_printf() calls into the code to narrow
this down further. One place is at the very end of queue_run() in the
queue.c module - after the log writing. Another might be after the call
to queue_run() in exim.c, just before it exits. If they all succeed, the
problem must be in the daemon.c module.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
