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

On Tue, Jun 08, 2021 at 06:39:15PM -0400, Randall S. Becker wrote:

On June 8, 2021 6:25 PM, Emily Shaffer wrote"

quoted

quoted

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