Description of problem:
This patch changes the behavior when there is a pipe in /proc/sys/core_pattern and it breaks ABRT.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install kernel 2.6.32
2. install abrt
3. crash something and instead of coredump you'll see this in dmesg:
Process 2739(gvfsd-trash) has RLIMIT_CORE set to 0
and abrt fails to detect it.
I see this too:
Process 2071(hal-disable-pol) has RLIMIT_CORE set to 0
If the patch is applied in koji, I'd be happy to test it.
a patch for this got pulled into -mm, I'll backport to rawhide, and kick off a koji build shortly.
Could you verify this build works the way you expect please?
just tried that kernel and ABRT detects crashes, but now the dump helper has troubles to readlink /proc/<pid>/exe, is it possible, that it disappears before the dump helper is done?
i'm glad it works. As for the dissappearing /proc/pid/exe files, you should read the git commit log more closely regarding the patch that started all this consternation. One of the reported bugs that that set fixes is the race between the cleanup of the crashing process and the collection of the dump. theres a new sysctl called core_pipe_limit that you need to set to guarantee the prevent that race condition. It only worked previously by good fortune
Ok, I will take a deeper look into it on Monday, now I gave it just a few minutes to install the kernel and test if abrt-hook is called when crash happens.
ok, let me know when you get to testing it
The second version seems to works fine, now I need to implement the core_pipe_limit setting in abrt.
commited to rawhide.
Has there been a kernel build since this was committed?
kernel -51 fixed this, I believe. I have tested abrt 1.0.8 plus kernel -52; abrt works in that combination.