apport forcefully overrides sysctl kernel.core_pattern from values set in /etc/sysctl.*

[Matthew Hall]

I think that the way apport registers itself as a core dump handler with the system is badly behaved with respect to other configuration processes one would expect to follow on a Debian or Ubuntu based system. It forcibly overrides settings specified by a user in /etc/sysctl.conf, and does not employ /etc/sysctl.d. Thus it is overriding settings that have been configured elsewhere upon start and upon shutdown.

I think perhaps it should be checking for non-default values in these settings and not dynamically playing with them while it starts and stops.

Thanks,
Matthew.

mhall@mhsm:src$ sudo fgrep kernel.core /etc/sysctl.conf
kernel.core_pattern = /var/crash/core.%e.%u.%t
kernel.core_uses_pid = 1
mhall@mhsm:src$

$ sudo sysctl -a | fgrep -i kernel.core
kernel.core_uses_pid = 1
kernel.core_pattern = |/usr/share/apport/apport %p %s %c
kernel.core_pipe_limit = 0

$ cat /etc/init/apport.conf
... SNIP ...
pre-start script
... SNIP ...
    echo "|/usr/share/apport/apport %p %s %c" > /proc/sys/kernel/core_pattern
... SNIP ...
post-stop script
... SNIP ...
    if [ "`dd if=/proc/sys/kernel/core_pattern count=1 bs=1 2>/dev/null`" != "|" ]
    then
 exit 1
    else
 echo "core" > /proc/sys/kernel/core_pattern
    fi
end script

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael (michaeljt)]

I have also just run into this after I tried to set a core pattern. I am rather divided on this - I would like to get my core patterns, but I also appreciate having Apport's functionality. So I would like a way to set the pattern for cores not handled by Apport. Perhaps a new sysctl (sys/kernel/core_pipe?) would be a better solution.

[justin (jlintz)]

Just got burned by this as well after upgrading to 12.04 in our infrastructure

[vi (istomin-vs)]

A few days ago we got suddenly affected by this after auto "upgrade apport 2.0.1-0ubuntu17.9 2.0.1-0ubuntu17.10".
We never had any need to change 'kernel.core_pattern' parameter in the past.
Sometimes, our coredumps are several GB large; so i expect apport to fail handling them anyway.
Then one would need the extra resources to now extract the coredump from a crash report.
The worst part is that after removing the package, the new 'kernel.core_pattern=core', which is plain wrong.

Now, we do have to worry about re-setting that back to the standard '/var/tmp/core.%e.%u.%g.%p.%s.%t'.

[Paul Smith (psmith-gnu)]

This is quite frustrating. I wish it would be addressed... somehow... (still getting this problem on 18.04 LTS).

[Zertrin (zertrin)]

Same surprise here, after adding a custom '/etc/sysctl.d/60-core_pattern.conf' to set it to my desired value, I could not understand why it seemed not applied after a reboot. Finally discovered the echoing inside '/etc/init/apport.conf' and died a little internally.

The proper course of action for apport would probably be to create its own '/etc/sysctl.d/30-core_pattern.conf' ("30" being documented as to be used by packages), instead of hijacking '/proc/sys/kernel/core_pattern' ...