28

using ulimit command, i set core file size.

ulimit -c unlimited

and I compiled c source code using gcc - g option. then a.out generated. after command

./a.out there is runtime error .

(core dumped)

but core file was not generated.(ex. core.294340)

how to generated core file?

y.selivonchyk
  • 8,987
  • 8
  • 54
  • 77
leeyc
  • 385
  • 2
  • 5
  • 13

4 Answers4

24

First make sure the container will write the cores to an existing location in the container filesystem. The core generation settings are set in the host, not in the container. Example:

echo '/cores/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

will generate cores in the folder /cores.

In your Dockerfile, create that folder:

RUN mkdir /cores

You need to specify the core size limit; the ulimit shell command would not work, cause it only affects at the current shell. You need to use the docker run option --ulimit with a soft and hard limit. After building the Docker image, run the container with something like:

docker run --ulimit core=-1 --mount source=coredumps_volume,target=/cores ab3ca583c907 ./a.out

where coredumps_volume is a volume you already created where the core will persist after the container is terminated. E.g.

docker volume create coredumps_volume
Gerardo Hernandez
  • 1,889
  • 1
  • 16
  • 20
  • 2
    Please replace `--ulimit core=99999999999:99999999999` by `--ulimit core=-1`. – SimonSimCity Feb 05 '20 at 13:21
  • 1
    How to change the path for per container: https://stackoverflow.com/questions/39136601/changing-proc-sys-kernel-core-pattern-file-inside-docker-container – SimonSimCity Feb 05 '20 at 13:23
  • 1
    How can the first command even work in a docker container, `/proc` is mounted as read-only? Basically you should be running into [this problem](https://stackoverflow.com/q/23840737/1804173). – bluenote10 Mar 03 '20 at 15:19
  • 1
    I could only make it work with `RUN mkdir /cores && chmod 777 /cores` in the Dockerfile (by default it had 755 permission and I was getting no dump file at all). Any idea why write permission to group/other is necessary, considering that my process runs as root? – aalazz Jun 12 '20 at 19:19
8

If you want to generate a core dump of an existing process, say using gcore, you need to start the container with --cap-add=SYS_PTRACE to allow a debugger running as root inside the container to attach to the process. (For core dumps on signals, see the other answer)

Gert van den Berg
  • 2,448
  • 31
  • 41
  • But would it be possible to call `gcore` from the host to avoid giving those rights to the container itself and having to put `gcore` in the image? – dolmen Feb 13 '20 at 10:21
  • @dolmen Yep, finding the process on the host might be hard, depending on how many containers are running – Gert van den Berg Feb 13 '20 at 13:51
3

I keep forgetting how to do it exactly and keep stumbling upon this question which provides marginal help.

All in all it is very simple:

  1. Run the container with extra params --ulimit core=-1 --privileged to allow coredumps:
docker run -it --rm \
--name something \
--ulimit core=-1  --privileged \
--security-opt seccomp=unconfined \
--entrypoint '/bin/bash' \
$IMAGE
  1. Then, once in container, set coredump location and start your failing script:
sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
myfailingscript.a
  1. Enjoy your stacktrace
cd /tmp; gdb -c `ls -t /tmp | grep core | tail -1`
y.selivonchyk
  • 8,987
  • 8
  • 54
  • 77
3

Well, let's resurrect an ancient thread.

If you're running Docker on Linux, then all of this is controlled by /proc/sys/kernel/core_pattern on your raw metal. That is, if you cat that file on bare metal and inside the container, they'll be the same. Note also the file is tricky to update. You have to use the tee method from some of the other posts.

 echo core | sudo tee /proc/sys/kernel/core_pattern

If you change it in bare metal, it gets changed in your container. So that also means that behavior is going to be based on where you're running your containers.

My containers don't run apport, but my bare metal did, so I wasn't getting cores. I did the above (I had already solved the ulimit -c thing), and suddenly I get core files in the current directory.

The key to this is understanding that it's your environment, your bare metal, that controls the contents of that file.

Joseph Larson
  • 8,530
  • 1
  • 19
  • 36
  • Note that the setting on your bare metal can get reset after a bounce. Apport doesn't like if you do this, after all, and he "knows better". Sigh. – Joseph Larson May 23 '23 at 20:14