Why don't you just start exim from the command line (as root) as in
"/usr/sbin/exim -bd -q15m" and see if the same problem happens? Of
course it should, if the startup process is all right. Also, it seems
that you do not necessarily need to start spamd (which can be
disabled independently), while I am not sure about antirelayd, what
the hell is that? A well configured exim does not relay blindly! Is
it perhaps a pop before smtp device? In short, hyst for testing, run
exim alone.
I noticed a few things from your reports:
At 13:44 -0500 2003/10/28, Steven Casey wrote:
>root@cpanel [/usr/sbin]# ps -ef | grep exim
>mailnull 32355 1 0 12:27 ? 00:00:00 [exim]
>mailnull 32360 1 0 12:27 ? 00:00:00 [exim]
>root 32366 32355 0 12:27 ? 00:00:00 [exim]
>mailnull 32367 32355 0 12:27 ? 00:00:00 [exim]
[...]
ok, two exim processes started by init (the second is the tls one).
But why a process owned by root?
Also note that the appendfile transport processes were killed by:
sys/signal.h:
#define SIGXFSZ 25 /* exceeded file size limit */
has the mailnull user very restrictive limits?
Also check that the /var/spool/exim (or equivalent) tree is owned by
mailnull and its group.
Sorry if these are a bit shots in the dark, but I am used to working systems...
Giuliano
--
H U M P H
|| |||
software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/
