Well, killing a production process may or may not be an appropriate action for the porcess. As Clay mentioned, several signals can be trapped and the application take the appropriate action, but many programmers don't handle all (or any) signals and the process abnormally terminates. Depending on the way the program works, data files may become corrupted. So indiscriminate kill commands can be bad for production programs and data.
However, kill -3 may be the only way a programmer can find out why a process is not working correctly, so it may be required. Now kill -3 (when it results in a core file) is unique in that the process memory area is copied to a disk file. That doesn't sound like much but it actually creates a heavy load on the system due to the tasks needed to rearrange memory. This causes spinlocks which are short pauses where all processing stops until the cire dump is complete. That may be the reason you heard that it's not a good idea to have core dumps on a running system.
Now that doesn't mean you should ban the practice. As with any heavy load on the system (like find / or du /), you don't do it very often. But if a core dump is the only way to discover the programming problem, then you'll have to do it. Note that the core dump does not introduce any instability in the system...it just slows down for a few seconds.
As Steven mentioned, you can limit core dumps as to size including zero (which prevents any core dump). The ulimit command in the shell can limit the maximum size of a core dump. Note that ulimit -c onloy works with the POSIX shell or a recently patched version of ksh.
Bill Hassell, sysadmin
