Apport doesn't forward crashes on containers.

[Jorge Niedbalski]

[Environment]

Wily / Trusty

[Description]

If any of the coredump signals (man 7 signals) is send to a process that runs inside a namespace,
then apport is not able to forward the crash into the right namespace, instead the following log entries are generated
on the host system /var/log/apport.log:

ERROR: apport (pid 30033) Thu Mar 10 12:20:36 2016: host pid 29763 crashed in a container without apport support
ERROR: apport (pid 30776) Thu Mar 10 12:23:48 2016: host pid 29734 crashed in a container without apport support

[Possible Solution]

I applied the following patch into the Host apport, this came from https://code.launchpad.net/~stgraber/apport/pidns-support/+merge/200893:

+
21 +# Check if we received a valid global PID (kernel >= 3.12). If we do,
22 +# then compare it with the local PID. If they don't match, it's an
23 +# indication that the crash originated from another PID namespace. In that
24 +# case, attempt to forward the crash to apport in that namespace. If
25 +# apport can't be found, then simply log an entry in the host error log
26 +# and exit 0.
27 +if len(sys.argv) == 5 and sys.argv[4].isdigit() and sys.argv[4] != sys.argv[1]:
28 + if os.path.exists("/proc/%s/root/%s" % (sys.argv[4], __file__)):
29 + os.execv("/usr/sbin/chroot", ("chroot", "/proc/%s/root/" % sys.argv[4],
30 + __file__, sys.argv[1], sys.argv[2],
31 + sys.argv[3]))
32 + else:
33 + error_log('pid %s crashed in a container without apport support' % sys.argv[4])
34 + sys.exit(0)
35 +

After applying this , the crashes are being correctly forwarded into the container.

So, I would like to propose this patch as an SRU for wily/trusty, but I don't know the full
list of drawbacks on this approach as the current code is using apport.socket (http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/3052)

[Martin Pitt (pitti)]

There was some moving history about that. We did have a working implementation in trusty/utopic, but disabled it due to bug 1438758, a privilege escalation which was basically unfixable (in a robust way) with the old design. But a few weeks ago that feature came back into xenial, now with a much safer design. See bug 1445064.

[Jorge Niedbalski (niedbalski)]

@pitti:

There is any way to backport/fix this behavior in Trusty/Wily?

[Martin Pitt (pitti)]

Wily never had container forwarding, so this would introduce a new feature, and I don't think it's really worth it for such a short-lived release. It's not possible to backport this to trusty as this relies on systemd socket activation. Upstart does not support this.