Solved How to enable system daemons' core dumps?

Bobi B.

Bobi B.

Greetings! Is there a standard way to enable core dumps for system daemons (the ones started from scripts in /etc/rc.d/)?

kern.corefile is set to /tmp/coredumps/%N.core and programs started from tcsh(1) create core dump files with dmesg(8) reporting that pid 74713 (willcrash), jid 0, uid 0: exited on signal 11 (core dumped). However some processes do not create a core dumps ( dmesg does not "say" (core dumped)), like squid, or, more importantly, some of our in-house daemons. Any hints where to look and what to check?
 
The obvious thing would be too small ulimit setting. There is another weird thing about processes changing their uid to something that cannot read their binary image, or such - I don't recall full details, but changing uid might well apply to system daemons, so you might look into that direction.

Ha, found it: core(5) :)
 
That is an interesting read, thanks! Regarding ulimit do you recall a "standard" way of setting it globally? for system processes, i.e. not ones started within interactive shell, but ones ran from startup scripts?
 
Aren't daemons just regular userland programs (run as root)? They should behave like any other userland program regarding coredumps, no?
 
Elazar said:
Aren't daemons just regular userland programs (run as root)? They should behave like any other userland program regarding coredumps, no?
Click to expand...
AFAIK ulimit is per-process and is applied to process itself and and sub-processes, therefore csh(1) selects max coredump size for itself and any programs one ran interactively. Hence one can change max coredump size using limit or ulimit builtins for current shell only. Having found dmesg(8) messages with and without (core dumped) related to system processes (ones started via rc(8) framework, not interactively) I'm looking for possible causes. But I could be wrong :-)
 
Bobi B. said:
That is an interesting read, thanks! Regarding ulimit do you recall a "standard" way of setting it globally? for system processes, i.e. not ones started within interactive shell, but ones ran from startup scripts?
Click to expand...
RTFM login.conf(5) & view +/daemon /etc/login.conf
But it seems that all daemons run with wheel real group id, not daemon?
 
Not every signal leads to a coredump, and an application can catch it's own signals too (see sigaction(2) about halfway down).

I know Samba does this, I've often see crash logs when, presumably, a thread bombs for some reason, they do some cleanup and just launch a new thread. However that's a more sophisticated technique and one I doubt system processes implement.
 
leebrown66 said:
Not every signal leads to a coredump, and an application can catch it's own signals too (see sigaction(2) about halfway down).
Click to expand...

Yeah, the signals that do coredump are listed in one of the pages linked from core(5). And certainly the application can decide to actively do something about it.

I know Samba does this, I've often see crash logs when, presumably, a thread bombs for some reason, they do some cleanup and just launch a new thread. However that's a more sophisticated technique and one I doubt system processes implement.
Click to expand...

Yes, firefox also does that, but then firefox does create a coredump, too.
 
You must log in or register to reply here.
Back
Top