On June 8, 2021 6:25 PM, Emily Shaffer wrote" >To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> >Cc: git@xxxxxxxxxxxxxxx; 'Ævar Arnfjörð Bjarmason' <avarab@xxxxxxxxx>; 'Junio C Hamano' <gitster@xxxxxxxxx>; 'Jeff Hostetler' ><git@xxxxxxxxxxxxxxxxx>; 'Bagas Sanjaya' <bagasdotme@xxxxxxxxx> >Subject: Re: [PATCH v5] tr2: log parent process name > >On Tue, Jun 08, 2021 at 06:16:57PM -0400, Randall S. Becker wrote: >> >> On June 8, 2021 6:11 PM, Emily Shaffer wrote: >> >It can be useful to tell who invoked Git - was it invoked manually by >> >a user via CLI or script? By an IDE? In some cases - like 'repo' >> >tool - we can influence the source code and set the GIT_TRACE2_PARENT_SID environment variable from the caller process. In 'repo''s >case, that parent SID is manipulated to include the string "repo", which means we can positively identify when Git was invoked by 'repo' >tool. >> >However, identifying parents that way requires both that we know >> >which tools invoke Git and that we have the ability to modify the source code of those tools. It cannot scale to keep up with the various >IDEs and wrappers which use Git, most of which we don't know about. >> >Learning which tools and wrappers invoke Git, and how, would give us insight to decide where to improve Git's usability and >performance. >> > >> >Unfortunately, there's no cross-platform reliable way to gather the >> >name of the parent process. If procfs is present, we can use that; >> >otherwise we will need to discover the name another way. However, the process ID should be sufficient to look up the process name on >most platforms, so that code may be shareable. >> > >> >Git for Windows gathers similar information and logs it as a "data_json" >> >event. However, since "data_json" has a variable format, it is >> >difficult to parse effectively in some languages; instead, let's pursue a dedicated "cmd_ancestry" event to record information about the >ancestry of the current process and a consistent, parseable way. >> > >> >Git for Windows also gathers information about more than one >> >generation of parent. In Linux further ancestry info can be gathered >> >with procfs, but it's unwieldy to do so. In the interest of later >> >moving Git for Windows ancestry logging to the 'cmd_ancestry' event, and in the interest of later adding more ancestry to the Linux >implementation - or of adding this functionality to other platforms which have an easier time walking the process tree - let's make >'cmd_ancestry' accept an array of parentage. >> >> We are probably going to have to discuss this one at more length. On >> NonStop, in some cases, I have access to the program arguments of the >> parent (rather like ps -ef) in POSIX-land, but not from the other >> personality. I do have access to the program object name, in both >> sides, although if someone replaces the object - which is not actually >> possible for a running program, but a rename is - the object may end >> up being somewhat meaningless or mangled. My suspicion is that I'm >> going to have to supply different things for the two personalities, >> but I'm not sure what as of yet. > >I guess I'm having trouble understanding - it sounds like you're describing one process with a graph of ancestry instead of a line. Does that >mean we shouldn't be tracing the ancestry the way we are? It's more like this (g = Guardian, p=Posix, for illustration), for a typical interactive situation coming from the non-POSIX side): gMonitor -> gAncestor1 -> gAncestor2 -> pAncestor3 (/bin/sh) -> git And when started from an SSH window: gMonitor -> gAncestor1 (SSH) -> pAncestor2 (/bin/sh) -> git I can get the program object name from any of the above, and the pid from a POSIX process, or the name (or cpu and process number) of a Guardian process. In the case of POSIX, obtaining program arguments may be possible. An ancestor, as with Linux, can have multiple children in a tree but a child can only have one parent - well, technically one at a time anyway because there are some funky exceptions where a child can adopt a different parent in Guardian-land. In both cases, I can get the program object file of the process (like /usr/local/bin/git), but if someone renames git because an install happened during a long-running operation, like git gc --aggressive, the object may be named something else, like /usr/local/bin/ZZLDAG01, for argument sake). I'm not sure any of this is really relevant, but describes some of what is possible. It also might be useful to pull out the tty that the process was running on. That is easy to get if the terminal is still connected. I think that particular bit of information might be very useful, as well as user information. -Randall
