Paul,
Interesting idea. I'll try that. I can just do it in bash me thinks
without adding another dependency.
Thanks,
Tom.
On Wed, 2004-01-07 at 12:37, Paul wrote:
> Run exim inside a wrapper script to capture any output to stderr and stdout
> when it does. RestartWrapper from open system consultants is one that comes
> to mind
>
> ----- Original Message -----
> From: "Thomas O'Dowd" <tpodowd@???>
> To: "Paul" <paul@???>
> Cc: <exim-users@???>
> Sent: Wednesday, January 07, 2004 2:28 PM
> Subject: Re: [Exim] exim dies silently
>
>
> > Hi Paul,
> >
> > I'm running Redhat 8. Memory test is clean. Kernel on that machine is
> > currently 2.4.20-20.8smp from RH.
> >
> > I have yet to get a coredump. I thought core dumps were enabled until
> > just now as I was doing a ulimit -a just before the command to start
> > exim ran. Only trouble was that the command to start it was the "daemon"
> > function from redhat. This function was setting the ulimit to not dump
> > core on me. I've just restarted exim again, overriding this so that core
> > should be dumped on a crash. I'll wait for the next crash to see if it
> > dumps core. I should also add that exim was compiled on this machine.
> >
> > In the meantime, any other ideas?
> >
> > Thanks!
> >
> > Tom.
> >
> > On Wed, 2004-01-07 at 12:07, Paul wrote:
> > > Thomas,
> > >
> > > No problems. I didnt realise it ran for a while before it crashed. Full
> > > debugging won't be feasible then :)
> > > Do you have any other apps doing the same thing? What OS? What kernel?
> Tried
> > > a memory test?
> > > Do you ever get stack dumps or page faults? core dumps in /var/log/dmesg
> > > (depending on OS ) ?
> > >
> > > ----- Original Message -----
> > > From: "Thomas O'Dowd" <tpodowd@???>
> > > To: "Paul" <paul@???>
> > > Cc: <exim-users@???>
> > > Sent: Wednesday, January 07, 2004 1:56 PM
> > > Subject: Re: [Exim] exim dies silently
> > >
> > >
> > > > Hi Paul,
> > > >
> > > > Thanks for your suggestion. Unfortunately (or fortunately depending on
> > > > how you look at it), exim doesn't crash that regularly. It can take a
> > > > day to crash or stay up for a week or two. I also can't pinpoint any
> > > > particular message that is causing the crash so its hard to turn on
> full
> > > > debugging in a useful way that won't fill the disk. Its also a
> > > > production server.
> > > >
> > > > thanks,
> > > >
> > > > Tom.
> > > >
> > > > On Wed, 2004-01-07 at 11:31, Paul wrote:
> > > > > try doing an exim debug. With version 3.x it was
> > > > > /usr/local/exim/bin/exim -d9 -bd
> > > > >
> > > > > and you'll get full console debugging. be aware it will be a lot of
> > > text. if
> > > > > its a live server, then make a copy of your config and run a new
> > > instance of
> > > > > the debug and bind it to say port 26 so you can run your debugging
> one
> > > as
> > > > > well as your normal one if its in production
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Thomas O'Dowd" <tpodowd@???>
> > > > > To: <exim-users@???>
> > > > > Sent: Wednesday, January 07, 2004 1:24 PM
> > > > > Subject: [Exim] exim dies silently
> > > > >
> > > > >
> > > > > > Dear all,
> > > > > >
> > > > > > I've been experiencing problems with EXIM dying silently on a
> Redhat 8
> > > > > > machine. I'm running 4.30 which I updated to recently. Previously
> I
> > > was
> > > > > > running 3.36 which was also crashing (main reason I decided
> updated).
> > > > > >
> > > > > > Exim 3.x had been running on a different machine running RH6.2 for
> me
> > > > > > for a long time with the same configuration. Recently we moved
> > > hardware
> > > > > > and OS version. Only after the move, did we start experiencing the
> > > > > > problem.
> > > > > >
> > > > > > This seems to suggest either a hardware or a problem with some
> library
> > > > > > on the new OS or some setting. The only problem is that I have
> other
> > > > > > long term running processes on this machine, including a
> relational
> > > > > > database and a few java based engines that don't crash. Exim is
> the
> > > only
> > > > > > process that experiences these problems. The new machine itself
> was
> > > also
> > > > > > in production previously and is running below capacity in terms of
> > > > > > memory and disk space. Its a twin cpu machine with 2GB of ram.
> > > > > >
> > > > > > Doing a "ulimit -a" just before exim is started by the start
> script,
> > > > > > shows the following.
> > > > > >
> > > > > > core file size (blocks, -c) unlimited
> > > > > > data seg size (kbytes, -d) unlimited
> > > > > > file size (blocks, -f) unlimited
> > > > > > max locked memory (kbytes, -l) unlimited
> > > > > > max memory size (kbytes, -m) unlimited
> > > > > > open files (-n) 1024
> > > > > > pipe size (512 bytes, -p) 8
> > > > > > stack size (kbytes, -s) 8192
> > > > > > cpu time (seconds, -t) unlimited
> > > > > > max user processes (-u) 7168
> > > > > > virtual memory (kbytes, -v) unlimited
> > > > > > Starting exim: [ OK ]
> > > > > >
> > > > > > So cpu time shouldn't be a problem. I've checked lsof and its not
> > > > > > running out of file descriptors. It just disappears from the
> process
> > > > > > list. Also, even though I allow it to dump core, it doesn't???
> > > > > >
> > > > > > There are no unusual entries in the mainlog/paniclog or rejectlog
> > > files.
> > > > > > There are a few frozen mails in the mailq but nothing extra
> ordinary.
> > > > > >
> > > > > > I'm running out ideas trying to debug this problem. Has anyone
> > > > > > experienced anything like this before?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Tom.
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > ## List details at http://www.exim.org/mailman/listinfo/exim-users
> > > Exim
> > > > > details at http://www.exim.org/ ##
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > ## List details at http://www.exim.org/mailman/listinfo/exim-users
> Exim
> > > details at http://www.exim.org/ ##
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
> details at http://www.exim.org/ ##
> >
> >
>
