<div dir="auto">I'll try that too. Thanks for mentioning it.<div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Amir</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 11 Dec 2025, 11:14 Michael Jeanson, <<a href="mailto:mjeanson@efficios.com">mjeanson@efficios.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/11/25 10:51, Amir Najafi Zadeh wrote:<br>
> Michael, Kienan, Thank you both for your replies. As you mentioned the <br>
> cgroup namespace, it isn’t very helpful in some cases. Containers may <br>
> share the same cgroup namespace, and the container runtime often avoids <br>
> giving each container a private cgroup namespace for performance and <br>
> security reasons. Because of this, the cgroup namespace can’t be used as <br>
> a reliable or unique label for filtering trace logs.<br>
> <br>
> In my case, with container-d you can inspect a container, find its PID, <br>
> and then check /proc/<pid>/ns/cgroup, but you’ll see that different <br>
> containers often have the same cgroup namespace ID (e.g., in the <br>
> following logs you can see the calico-node and kube-proxy containers <br>
> sharing a cgroup ns).<br>
<br>
If you want to track containers, the pid namespace is the one used by <br>
most container runtimes but I don't know specifically for container-d.<br>
<br>
> <br>
> ```<br>
> Name: calico-node  CID: <br>
> b5624afe31b005725f4ba53c7b6fe758f3c09fabf013085231ff8b97588f6ace  PID: <br>
> 2243  cgroup_ns_inode: 4026531835<br>
> Name: kube-proxy  CID: <br>
> 52f3c12def7a680f61a925ac92dd5ebd5eba6cad17d671efbfd1d40db7dff624  PID: <br>
> 1851  cgroup_ns_inode: 4026531835<br>
>    >> MATCH FOUND: shares ns with container: <br>
> b5624afe31b005725f4ba53c7b6fe758f3c09fabf013085231ff8b97588f6ace <br>
> (calico-node)<br>
> ```<br>
> <br>
> Thanks again for your answers. I hope this feature appears in a future <br>
> patch.<br>
> <br>
> Best,<br>
> Amir<br>
> <br>
> On Thu, Dec 11, 2025 at 9:57 AM Michael Jeanson <<a href="mailto:mjeanson@efficios.com" target="_blank" rel="noreferrer">mjeanson@efficios.com</a> <br>
> <mailto:<a href="mailto:mjeanson@efficios.com" target="_blank" rel="noreferrer">mjeanson@efficios.com</a>>> wrote:<br>
> <br>
>     On 12/11/25 09:30, Kienan Stewart via lttng-dev wrote:<br>
>      > Hi Amir,<br>
>      ><br>
>      > On 12/10/25 9:40 PM, Amir Najafi Zadeh via lttng-dev wrote:<br>
>      >> Hello everyone,<br>
>      >><br>
>      >> I hope you’re doing well. My name is Amir, and I’m a PhD student in<br>
>      >> the Computer Science department at Stony Brook University, New York.<br>
>      >><br>
>      >> I have a question about the LTTng context that I haven’t been<br>
>     able to<br>
>      >> find an answer for in the docs or man pages. Does LTTng support<br>
>     adding<br>
>      >> the cgroup ID or cgroup path as a context field? I want to<br>
>     filter my<br>
>      >> trace results based on cgroups.<br>
>      >><br>
>      ><br>
>      > I think you're looking for the `cgroup_ns` context which adds the<br>
>     inum<br>
>      > of the cgroup namespace as a context field.<br>
> <br>
>     This will give you the ID of the cgroup namespace but we don't have<br>
>     contexts for cgroups themselves. It's probably something we would like<br>
>     to have but there is no concrete plans on implementing this at the<br>
>     moment.<br>
> <br>
>      ><br>
>      >> If this isn’t supported, are there any plans to add it in future<br>
>      >> versions, such as 2.14?<br>
>      >><br>
>      >> For reference, I’m currently using LTTng 2.13 on Ubuntu 24.04 with<br>
>      >> kernel 6.8.0-87-generic.<br>
>      >><br>
>      >> Cheers,<br>
>      >> Amir<br>
>      >> --<br>
>      >> *Amirhossein Najafizadeh*<br>
>      >> *PhD Student, Computer Science Department, Stony Brook<br>
>     University, N.Y.<br>
>      >> File systems and Storage Lab (FSL)<br>
> <br>
<br>
</blockquote></div>