From mboxrd@z Thu Jan  1 00:00:00 1970
From: loic.gelle@polymtl.ca (=?utf-8?b?TG/Dr2M=?= Gelle)
Date: Mon, 27 Aug 2018 15:26:36 +0000
Subject: [lttng-dev] RFC: More flexible support for UST event collection
 in containers
In-Reply-To: <20180801173614.Horde.ZvKFlt_4hfXqTXVGAy1Ck_S@www.imp.polymtl.ca>
Message-ID: <20180827152636.Horde.-01OQAaWI7v3hpg9iiRFhuu@www.imp.polymtl.ca>

Hi all,

Any reactions to my previous message?

Thanks,
Loïc.

Loïc Gelle <loic.gelle at polymtl.ca> a écrit :

> Hi all,
>
> I am writing a proof of concept for LTTng (ust + tools) for better  
> support of application tracing in containers. My point is that we  
> should be able to collect all UST events emitted from within  
> containers using a single sessiond / consumerd, at least if you want  
> to. The main problem to that approach was that the session deamon  
> was unable to handle PID clashes when two apps with the same vpid  
> tried to register. I fix this by patching the UST client for it to  
> declare both its PID and its PID namespace inode number during  
> registration (and I also propagated the change to lttng-tools for  
> app registration in the hashtable). My patched versions of tools and  
> UST are here, in the branch "containers":
>
> https://github.com/loicgelle/lttng-ust
> https://github.com/loicgelle/lttng-tools
>
> One problem that I have now is that LTTng-tools currently uses  
> /proc/[pid]/cmdline to fetch the name of each application when  
> listing the available tracepoints. This is a problem since we have  
> no (simple) way to know the PID of the registered apps in the  
> context of the PID namespace of sessiond, so this step basically  
> fails. I thought that a fix for this would be to ask the  
> applications themselves to declare their name using their dedicated  
> socket. Do you think that would be possible and relevant?
>
> Also, if you like the idea that I'm pushing, there is more work  
> ahead to make it a feature (for example propagating the changes to  
> pid tracking).
>
> Thanks,
> Loïc.
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev