If the kernel kills a process due to an out of memory error, it
can be difficult to track the process back to the build that triggered
it. The kernel error just gives us a PID, but we don't know any of
the Ansible process ids. Further, since they are in bwrap, Ansible
only knows its namespaced pid rather than the host pid, so we can't
simply output it in one of our callback plugins.
To aid in debugging, output all of the process ids within a namespace
right at the start of an ansible-playbook execution. At this time,
it is certain that the Ansible process will have started, and it is
very likely that it is still running. That should provide a way
to map from an OOM message back to an Ansible process id.
(Note that Ansible forks and this is unlikely to catch any forked
processes, so we will only see the main Ansible process id. Typically
this is what the kernel should elect to kill, but if it does not,
we may need a futher change to repeat this process each time Ansible
forks. Since that is more costly, let's see if we can avoid it.)
Change-Id: I9f262c3a3c5410427b0fb301cb4f1697b033ba2f
1c92165ab7