[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cores

You also have to do some futzing to get anything that has changed its effective uid to dump core. We're able to make Apache dump core on UMCE Linux, though.

It took a while to figure it out, but boy are we ever able to make Apache dump core. ;)


On May 13, 2004, at 12:41 AM, Marcus Watts wrote:

Sean Sweda <sweda@xxxxxxxxx> writes:
Message-Id: <B028D469-A463-11D8-A798-000A95A4FDDA@xxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: UMCE Linux <umce.linux@xxxxxxxxx>
From: Sean Sweda <sweda@xxxxxxxxx>
Subject: cores
Date: Wed, 12 May 2004 18:28:27 -0400

We were discussing core files at the blackops meeting.  To the best of
my knowledge we have not had any core dumps cause a tripwire on our
production servers running UMCE linux.  I'd like to believe that
nothing has ever crashed, but with wonderfully gnarly stuff like bind,
sendmail, and openldap running I suspect that we have had a thing or
two die since we first started deploying last summer (I also have
strace output of our virus milter which shows threads segfaulting
repeatedly).  Of course, everything could be crashing and coring in
negative directories and not causing tripwire.  However, I know that
slapd died on serpico.dir last week and find does not reveal a core

serpico-root# find . -name core

So... my question to you all is this:  have you seen core files left
over on your servers, and if so what left them behind?  I'm wondering
if we have some kind of systemic problem which is preventing them from
being written out.

Please discuss.


bash-2.05b$ ulimit -a core file size (blocks, -c) 0 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 bash-2.05b$

Not sure right off where the limit comes from exactly (kernel? init?)
but the consequence is certainly that we won't get any of those
pesky core dumps filling up our disks.



... "you can't give yourself a nickname." ...