I mean if I see core.<pid> in filesystem does it mean that core file generation finished and I can use it on my own?

My question was answered. But I decided to explain it a little bit.
I supposed that core.<pid> is generated in some hidden file f.e. .code.<pid>~ first and only after generation finished just moved (renamed) to target path. In that case operation can be fast and atomic.

  • You purpose is not clear. Could you details your goals? – Rui F Ribeiro Jan 11 '16 at 17:02

I wouldn't bet on it, especially on a busy multithreaded system, or if the dump location is on a network share (memorably, a professor would generate 8 GB core files that had to be spooled over 10Mbit ethernet via NFS). File system atomicity usually requires locking, or the write-to-a-temporary-file-and-then-rename(1) trick. Some delving around in fs/coredump.c for the linux 4.3.3 kernel indicates no such locking or rename tricks, as the kernel figures out the filename to use (with an unlinking race condition!) and then spools out the file:

        core_dumped = binfmt->core_dump(&cprm);

Since there's probably no giant kernel lock to prevent other user-land things from running while the above is doing its business (this could be tested by slowing down the generation of a large core file, then seeing how that system behaves), I don't see anything atomic about this process.

| improve this answer | |

No, like any other file it appears in the file system at the point when writes to it start, not when it's finished and closed.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.