Hi, Todd, Murray,
thanks a lot for all the help! Currently I have no access to the system,
but I'm pretty sure these instructions will prove to be very helpful in
the future.
Regards,
/rolf
On 11/25/11 4:03 PM, Todd Lyons wrote:
> On Fri, Nov 25, 2011 at 1:53 AM, Murray S. Kucherawy<msk_at_blackops.org> wrote:
>>> No, as far as I can see it didn't. I assume the name of the core would
>>> just be 'core'?
>> Linux is picky about under which conditions it will leave a core; see
>> http://linux.die.net/man/5/core. That page also tells you how it will be
>> named. The EnableCoreDumps config file item sets PR_SET_DUMPABLE with
>> prctl(), which you'll see referenced at that page in the case that you're
>> using UserID (which you are) to run as a different user.
> By default, most linux distros won't leave cores laying around. I'll
> describe how it works on a CentOS box, it should basically be the same
> for The easiest way to get a core is to:
> 1. Make sure opendkim is running. Start it temporarily if it's not.
> 2. 'ps auxww | grep [o]pendkim' and look for the full commandline that
> opendkim is being run with.
> 3. Optional: Start screen (it will just look like a bash shell unless
> you have changed the .screenrc to show some kind of status line)
> 4. Stop the opendkim daemon.
> 5. 'ulimit -c 1000000' , which will configure your shell (and only
> this shell, won't affect other apps on this box) to leave a core if
> there is a segfault.
> 6. If your opendkim runs as a user that is not root, you need to be in
> a directory that this user has write access. A good bet is to 'cd
> /tmp'
> 7. Run the command you saw in #2, but add -f to the commandline. That
> will tell it not to daemonize and stay in the foreground.
> 8. When it segfaults, it will say "Segfault (core dumped)" instead of
> just "Segfault".
> 9. The core file will be named core.XXXXX where XXXXX is the PID of
> the app that segfaulted.
> 10. 'gdb /usr/local/sbin/opendkim /tmp/core.XXXXX' is how I get into
> the debugger with that core; adjust for the location of your opendkim
> binary. Follow Murray's instructions of what to run and what output
> he wants to see when this happens.
> 11. Optional: If you ran this in screen, you can exit screen with
> "Ctrl-A D" (to disconnect the screen) and wait for it to segfault.
> Once it segfaults, you can run 'screen -x' to re-attach to that
> disconnected session and do the steps 8-10 above and Murray's
> instructions below.
>
> I'll also note that Murray is very responsive in real time on the
> #dkim irc channel on EFNet. However, for this long holiday weekend,
> I'm sure his availability is sporadic.
>
>> In either case, typing "where" inside gdb once you've captured the problem
>> will get you a stack trace on the thread that hit the assertion failure,
>> which is a good starting place to figuring out what's going on here.
> ** Murray, it might be useful to put a debugging section somewhere in
> the docs that discusses how to do the above when there is a bug. It's
> something that I didn't know much about until the couple of times I
> have had to drill down and debug things with you, and most admins
> don't seem to know how to use gdb unless they happen to be
> programmers.
>
> Regards... Todd
>
Received on Fri Nov 25 2011 - 18:20:21 PST