Commit Graph

2 Commits

Author SHA1 Message Date
James E. Blair 1c92165ab7 List process ids in bwrap namespace
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
2023-06-28 13:31:06 -07:00
James E. Blair ce56ff9756 Add wrapper driver execution context
We recently began altering the mount map used by the wrapper driver
for each execution run (so that we can only include the current
playbook).  However, the setMountsMap method operates on the global
driver object rather than an object more closely bound to the lifetime
of the playbook run.  The fact that this works at all is just luck
(executing process is slow enough that hitting a race condition where
the wrong directories are mounted is unlikely).

To correct this, add a new layer which contains the context for the
current playbook execution.

Change-Id: I3a06f19e88435a49c7b9aea4e1221b812f5a43d0
2017-08-18 16:35:12 -07:00