Problem getting or finding core dumps

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem getting or finding core dumps

Damon Getsman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

  I've got a problem with a piece of non-BSD software that I'm running
on my OpenBSD 5.4 system.  I'm not looking to you guys for help with it
at all; I'm working closely with the developers on it.  However, it
turns out that it's not at a stage where it's receiving almost daily
segfaults knocking it out of the active processes.  Strangely enough,
though I'm able to get .core files from many of the related programs
that are along with it, when bad things happen to them, this one
primary daemon won't leave a core file.
  I've checked my ulimits, specifically 'ulimit -u' under the user that
this is running as, and I'm only finding that it's 'unlimited'.  As far
as I know, that means that I _should_ be getting a core file
somewhere.  The process name is 'sbbs', and I've searched (as root) my
entire filesystem, not just the small separate filesystem that this
resides on, doing a general search, grepping for 'core', and then
searching through it for 'sbbs', and I'm not finding the file that I
need anywhere.
  The developers do not have any OpenBSD machines available for work on
this software, but they do want to help.  Getting that stack trace is
the only thing that might get around any issues, at this point, or
point in the right direction for where to go with things.  I know
OpenBSD fairly well, but when it comes to kernel internals and things
along the lines of core debugging and [a lot of the] ulimits, I'm still
somewhat in the dark.
  Can anybody tell me if I'm missing anything obvious, and what I might
be able to do to force a core dump next time this guy segfaults?  I
really need to get my hands on that stack and I'm clueless here.  I use
this package as a fully featured communications hub for myself and
several other users, and short of the kludgy solution of running a cron
script job that checks for the process, verifies its health, and
respawns a new process if necessary every few minutes, I don't know
what to do.  I'd much handle things the right way, and learn a bit more
about my favorite OS along the way.
  Any help is appreciated, feel free to get ahold of me any which way;
telnet to tinfoil.synchro.net if you'd like to see the small text
portion of the system in action.  ;)  All of the other provided
services in the suite are temporarily blocked by the firewall due to my
not having admin privileges on this network.

  -Damon Getsman

- --

Opinions expressed are not necessarily those of the owner of this
corporeal, rotting porksuit, nor its fiat-currency waving handlers.

- -Damo
iF4EAREIAAYFAlSUk+kACgkQerX40lUXtCPACAD7By2Fpp222QHyp0Iu2TAD+p71
79wp9Duc+W4/cxkpNPEBAJeFLuJd/PJHgXQht4ffcHg4QXSoElgPK7L/LjF2XnCI
=Lnqk
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Problem getting or finding core dumps

Theo de Raadt
>   I've checked my ulimits, specifically 'ulimit -u' under the user that
> this is running as, and I'm only finding that it's 'unlimited'.  As far
> as I know, that means that I _should_ be getting a core file
> somewhere.  The process name is 'sbbs', and I've searched (as root) my
> entire filesystem, not just the small separate filesystem that this
> resides on, doing a general search, grepping for 'core', and then
> searching through it for 'sbbs', and I'm not finding the file that I
> need anywhere.

Probably a uid/gid changing daemon.

% man core
...
CAVEATS
     Programs which are started with either the set-user-ID or set-group-ID
     bits set, or which change their UID or GID after starting, will normally
     not dump core.  This is to prevent sensitive information from
     inadvertently ending up on disk.  This behaviour can be changed (for
     debugging purposes) by changing the kern.nosuidcoredump sysctl(3)
     variable to the right settings.

% man sysctl
...
     To place core dumps from issetugid(2) programs (in this example bgpd(8))
     into a safe place for debugging purposes:

           # mkdir /var/crash/bgpd
           # chmod 700 /var/crash/bgpd
           # sysctl kern.nosuidcoredump=3

Reply | Threaded
Open this post in threaded view
|

Re: Problem getting or finding core dumps

Ingo Schwarze
In reply to this post by Damon Getsman
Hi Damo,

Damo Gets wrote on Fri, Dec 19, 2014 at 01:08:57PM -0800:

>   I've got a problem with a piece of non-BSD software that I'm running
> on my OpenBSD 5.4 system.  I'm not looking to you guys for help with it
> at all; I'm working closely with the developers on it.  However, it
> turns out that it's not at a stage where it's receiving almost daily
> segfaults knocking it out of the active processes.  Strangely enough,
> though I'm able to get .core files from many of the related programs
> that are along with it, when bad things happen to them, this one
> primary daemon won't leave a core file.
[...]

Just guessing, but it sounds a bit like that primary daemon
does privilege dropping (which would indeed be reasonable for a
daemon).  In that case, did you allow it to dump core?

The sysctl(8) manual contains a very brief entry and an example,
sysctl(3) some more information, look for "core" in both.

In case you are forced to loosen these settings on a production
system, you might wish to loosen them as little as possible,
for example creating a directory /var/crash/sbbs, granting
no unnecessary permissions on it to anyone, and run with

  sysctl kern.nosuidcoredump=3

Yours,
  Ingo