core dups generated every 10 minutes in /cores

i did not figure out why is my server creating core dumps. i saw a lot of crashes in the kerio mail server log in the crashreported and the time matched the core dumps time, so i assuem it is kerio. i was able to stop the server from creating core dumps at all though ** lookign at this article:
http://blog.e-shell.org/14
and here it is pasted as well:
hope this helps someone ...
martin

OSx has its roots in the Unix world. It is based on Mach 3.0 and FreeBSD 5, so you could expect some Unix-like behaviour from it.

One of those things that have been laying around in the Unix lair for a loooong time are cores or core dumps. A core is a file that appears when an application crashes, usually with a segmentation fault or some other kind of ugly error. Inside that file, if you use some proper application to examine it, you will find a memory dump, that is, the in-memory space using by the application while it was running.

As I've said, using tools like ddd or gdb you could learn a lot about how and why the application crashes, and that information is very important when doing software development.

The problem with that core files is that they are usually very big, that is, something between 300Mb and 1Gb (depending on the ammount of memory in your computer). That means that when a core appears, a lot of space is wasted (well, at least wasted if you are not a developer debugging some app).

In other systems like FreeBSD, OpenBSD or some Linux distributions, those core files appeared inside the directory from which the application is called, which in most cases is the home of the user running the application. That's fine, because you will notice those big files and you can delete them whenever you want.

In OSx the core files are saved somewhere else, in a someway hidden directory, called /cores (well, not completely hidden, but difficult to find for non-expert users). That was my case 2 days ago, while doing some housekeeing work in my Macbook, I found that directory wasting around 1Gb of disk space:

snowball:/ Wu$ sudo du -sh *

[ ... ]

1.0G cores

[ ... ]

snowball:/ Wu$ ls -l cores/
total 2110848
-r-------- 1 Wu admin 152924160 Feb 27 2007 core.1216
-r-------- 1 Wu admin 168681472 Feb 21 2007 core.24998
-r-------- 1 Wu admin 168681472 Feb 21 2007 core.25018
-r-------- 1 Wu admin 590467072 Apr 16 2007 core.8464
snowball:/ Wu$

As you probably noticed, the core files are quite older, from February and April, and I do not need them anymore, so I deleted them directly:

snowball:/ Wu$ rm -f cores/*
snowball:/ Wu$

(remember to use the -f switch, because they are protected read-only)

In my case it wasn't a big deal, it was only a matter of 1Gb, but getting more crashes will mean more core files, and the filesystem being filled with some data probably you will never use. So it is a good idea to take a look inside /cores from time to time, and delete the cores you do not need.

The other option is to prevent OSx from creating core files at all, we can achieve that using sysctl:

snowball:~ Wu$ sysctl kern.coredump
kern.coredump = 1
snowball:~ Wu$

That means core dump creation is activated, we can disable it manually:

snowball:~ Wu$ sudo sysctl -w kern.coredump=0
kern.coredump: 1 -> 0
snowball:~ Wu$ sysctl kern.coredump
kern.coredump = 0
snowball:~ Wu$

And then adding one line to /etc/sysctl.conf so dump creation keeps disabled on the next reboot:

kern.coredump=0