2

I have a problem where a Python process is hitting a segmentation fault but not producing a core file.

The following is a toy example that does not produce a core file on the following distros:

  • Ubuntu 12.10
  • Fedora 18

but does produce core files on the following distros:

  • Scientific Linux 6
  • Mac OS X

The reproduction:

$ python -c 'import time; time.sleep(120)'&    
$ kill -abrt $!   [1]+   
Aborted                 python -c 'import time; time.sleep(120)'  
$ ls core*   ls: cannot access core*: No such file or directory  

However, if I send a similar signal to a sleep instance I do get a core file:

$ sleep 120 &  
$ kill -abrt $!  
[1]+  Aborted                 (core dumped) sleep 120  
$ ls core*  
core.8603  

On my Fedora 18 box, here is my /proc/sys/kernel/core_pattern:

$ cat /proc/sys/kernel/core_pattern   
core

And I've set the following:

$ ulimit -c  
unlimited

This is reproducible regardless of whether the abrtd service is running or not.

I'm pretty sure I've missed some basic configuration, but I don't know what. Thanks!

EDIT: This may be solvable by running:

$ echo 1 >/proc/sys/fs/suid_dumpable
4
  • Is core a program on your system? What have you tried? Which of these has not solved your problem? wiki.ubuntu.com/Apport , ubuntuforums.org/archive/index.php/t-497562.html , stackoverflow.com/questions/5833218/… Jul 20, 2013 at 8:06
  • Did you try setting suid_dumpable to 1? (only root can do that) Jul 23, 2013 at 20:17
  • 1
    Please try following: ls -lL $(which python) ; python -c 'import time; time.sleep(5)' & grep core /proc/$!/limits ; ls -ld "$(readlink /proc/$!/cwd)" ; grep ^Sig /proc/$!/status ; kill $! The sequence will 1. list the Python binary to check if it is not suid; 2. list actual core limit of the process to check if it did not change; 3. list the working directory of the process to check if it is writeable by the user; 4. list signal masks of the process - please check if the SIGABRT (6) showing as 0000000000000020 is not blocked SigBlk, ignored SigIgn or caught SigCgt. Jul 23, 2013 at 20:26
  • Although not directly related to the above example, if your python process happens to use the "daemon" module to put itself in the background that defaults to explicitly turning off core dumps. You need to set prevent_core=False in the DaemonContext to override that.
    – Eric
    Sep 11, 2017 at 16:36

1 Answer 1

2

tl;dr

$ echo 1 >/proc/sys/fs/suid_dumpable

(or the equivalent in /etc/sysctl.conf to persist the change across reboots)

longer

In my scenario I was using setcap to set certain capabilities on my Python process, to e.g. allow the use of raw sockets without having to be root. With this enabled you need to be root to get a core dump, or use the above command to explicitly tell the kernel it's OK for non-root users to get core dumps that they themselves can access.

(setting 2 would still enable core dumps in this situation but the said core dumps would only be accessible by the root user).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .