Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

$ 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*

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

$ cat /proc/sys/kernel/core_pattern

And I've set the following:

$ ulimit -c

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

share|improve this question
Is core a program on your system? What have you tried? Which of these has not solved your problem? , ,… – Ярослав Рахматуллин Jul 20 '13 at 8:06
Did you try setting suid_dumpable to 1? (only root can do that) – pabouk Jul 23 '13 at 20:17
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. – pabouk Jul 23 '13 at 20:26
up vote 1 down vote accepted


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

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


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).

share|improve this answer

You must log in to answer this question.

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