Re: [PATCH v5] tr2: log parent process name

[Emily Shaffer <emilyshaffer@google.com>]

On Tue, Jun 08, 2021 at 06:39:15PM -0400, Randall S. Becker wrote:
> On June 8, 2021 6:25 PM, Emily Shaffer wrote"
> >> 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).

Interesting. One thing that might be helpful (if you don't care about
the later name, since it looks like it might be junk) is that
trace2_collect_process_info() provides some hint about when it was
invoked, via the 'enum trace2_process_info_reason' arg. So if you're
worried about a long-running process being renamed, the
TRACE2_PROCESS_INFO_STARTUP reason happens very early in common-main.c.
(And you could capture info like "the name changed later" at
TRACE2_PROCESS_INFO_EXIT if you wanted.)

> 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
> 

(I don't have much insight into what would or wouldn't be useful to log
here in your case, but I will say that it all sounds very cool and I
appreciate your thorough explanation.)

 - Emily