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
file:
serpico-root# find . -name core
./dev/core
./proc/sys/net/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.
Sean
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.
-Marcus
!DSPAM:40a2fd6f167231157314280!