Log process exit time about snoopy

[serkan-ozal]

Ok, thanks for the info 👍 For now, BPF based solution seems the best way for us to go.

[bostjan]

Hey @serkan-ozal,

What's the actual use case that you'd want to solve with such a feature? Personally, I've never needed such information from Snoopy, because I was able to tell, from the command itself, for how long it has been running - it's either in the order or seconds, or days/weeks. In the past, for the stuff that I needed the execution time (it was a PHP application), I've built those measurements into the PHP itself.

Technicalities

First of all, Snoopy's current approach to operation is kinda hands-off:

• It gets preloaded into the program's memory.
• It simply intercepts calls to exec()/execve(),
• It logs what's about to be executed,
• Then it continues with the actual execv()/execve() call.
  At that point, Snoopy is out of the picture again and doing nothing until execv()/execve() is (potentially) called again. Snoopy also keeps no state information.

Also, in the child process, up to this point, Snoopy does nothing:

• It it simply preloaded by the dynamic loader.
• And then it waits for the first execv()/execve() call.
  Meanwhile the child process is doing whatever it is doing.

Technically (to some extent, according to my quick googling) what you're asking for may be doable with:

• The atexit() libc facility from within the child, but it may not work in exactly the cases you'd need it the most - see first paragraph in the "Notes" section,
• Or by trying to hook into the parent's handling of child exit routine (wait()/waitpid()), but by then, most of the information of the child process might already be gone (meaning we'd need to keep a state internally with that information stored, which is another can of worms).

Please describe your use case and let's then discuss further.

PS: Have you checked alternative solutions for this, things like Linux' implementation of BSD process accounting, Linux's auditd subsystem or maybe even a BPF?

[serkan-ozal]

Hi @bostjan,

The use case is that we want to trace processes with their

• name,
• start time,
• end time (or duration),
• args,
• exit code

In addition to snoopy, we have also considered using process accounting, auditd and BPF. However, as far as we experiment, currently only BPF based https://github.com/iovisor/bcc/blob/master/tools/exitsnoop.py does what we want to be able to get process exit time with its exit code.

[bostjan]

Haha, @serkan-ozal, I had more the "why, to what purpose?" question in mind, no the details of what you'd want to be collected to fulfil said purpose. :) (BTW feel free to not share this information, I understand it might be considered private.)

That said, and given how Snoopy currently (and since forever) operates, I don't think this feature is a good fit for Snoopy's current internal architecture. Refactoring from ld.so.preload-based(-only) operation to BPF (for triggers) + daemon (for trigger consumption + log event creation) is no small feat, and it's probably simpler to just create a new tool, something similar to exitsnoop you found.