Federico Di Pierro

Update: the aforementioned PR has been merged. We just need to wait for a containerd tag now. Hopefully it will come soon.

Whoa didn't expect differences given the implementation :O let me try to understand what's happening! Thanks for the feedback btw!

It seems like it solved itself. But the upstream issue is still open; i'd leave this open as a reference if the problem strikes back!

/milestone 0.19.0

Ehy! I can see the correct driver being there: https://d20hasrqv82i0q.cloudfront.net/driver/site/index.html?lib=8.1.0%2Bdriver&target=ubuntu-generic&arch=x86_64&kind=kmod&search=falco_ubuntu-generic_6.8.0-64-generic_67.ko I don't get the issue; how are you installing Falco? When installing through either deb/rpm package or charts, `falcoctl driver...

Hi! Thanks for opening this issue! > in general it is running great. First of all, i am really happy that it's working great for you :) So, the first...

Also, it's pretty weird that the container metadata are present in the event: ``` "container.id": "93134a5f4b04", "container.image.repository": "dynatrace-managed-nonprod.erste-group.net/linux/oneagent", "container.image.tag": "1.313.45-raw", "container.name": "dynatrace-oneagent", ``` EDIT: i mean, if metadata are present...

In the metric snapshot, i see: > "plugins.container.n_containers":99 Thus there are many containers! Sorry for the noise but i indeed needed `trace` libs_logger severity: https://github.com/falcosecurity/plugins/blob/main/plugins/container/src/caps/async/async.cpp#L57 This way, we can analyze...

Oh ok i understood what's happening: * during startup time, container plugin loads all pre-existing containers, stores them in its own cache and send a `container` event for each of...

So, here there are 2 issues, as you are correctly highlighting: * `thread.cap_permitted` extractor is exacting caps that are not really attached * the `tid` sent within the `container` event...