I was reading Michael Kerrisk's "Namespaces in operation" (http://lwn.net/Articles/531114/), which explains most of the namespace functionalities, and this brings to mind a number of questions.
Are trace paths namespace-ready? Per-PID traces are apparently not much at risk since a process can join a PID namespace only upon its creation (that is to say, PIDs are immutable). However, collisions are still possible, such as if two user-space processes start within the same one-second window in two sibling PID namespaces such that they have the same virtual PID. But what of per-UID traces? What happens to a trace in progress if one or more processes switch user namespaces? Presumably new sub-directories would be created under "session-name/ust/uid/"? What about the case where two processes run by two different users (and thus being recorded under different uid subdirectories) switch to private user namespaces which happen to both map to the same numerical virtual uid? We need to make sure the second process switch does not overwrite the trace files of the first (recall that per-uid trace paths do not include timestamps like per-pid trace paths do). Finally, in the case of a remote trace being received by the relay daemon, could a network or UTS namespace switch of the traced processes cause trouble? I suspect not, since the daemons at either end of the connection are lttng-owned and would presumably not undergo namespace switches themselves. Daniel U. Thibault Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS) R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier) 2459 route de la Bravoure Québec QC G3J 1X5 CANADA Vox : (418) 844-4000 x4245 Fax : (418) 844-4538 NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ> Gouvernement du Canada | Government of Canada <http://www.valcartier.drdc-rddc.gc.ca/> _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
