It seems the new bpftrace version since 0.22 logs a warning if we try to
delete a key that does not exist.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
On bpftrace 0.22 this fails to compile and load so the script currently
does not show us anything in CI there.
We need to clamp the string size a bit 128 chars seems more than enough
for the podman/conmon binary path length.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The default has been set to 1024 which should bee good enough and better
than having to unroll this loop like that.
This is supported since bpftrace 0.22 which is in fedora 42.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This reverts commit d633824a9527b9ec937cdfc8aacc890ec3249127.
The issue has been fixed in commit 9a0c0b2eef and I have not seen it
since so remove this special case.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Debug for #23913, I though if we have no idea which process is nuking
the volume then we need to figure this out. As there is no reproducer
we can (ab)use the cleanup tracer. Simply trace all unlink syscalls to
see which process deletes our special named volume. Given the volume
name is used as path on the fs and is deleted on volume rm we should
know exactly which process deleted it the next time hopefully.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add a new program based on bpftrace[1] to trace all podman processes
with arguments and exit code/signals. Additionally this captures stderr
from all podman container cleanup processes spawned by conmon which
otherwise go to /dev/null and are never seen in any CI logs.
Hopefull this allows us to debug strange network cleanup error seen in
CI, my plan is to add this to the cirrus setup and upload the logs so we
can check them when the flakes happen.
[1] https://github.com/bpftrace/bpftrace
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
