13

Sometimes a process comes and goes faster than I can ps aux, I tried watch -d -n0.1 "ps aux | tail" but again, that's restricted to 1/10th of a second. What I really want is to run a command and follow all new processes, one per line, as they spawn. Even processes that run fast. I know strace has abilities similar to this but I haven't been able to get it to do what I want.

tl;dr : is there a way to log all new processes?

I don't want to know much, no more than a line of ps aux would give me, for the current case I just have a process that's spawned by another and disappears, I want to be able to run it, but I don't know what the command would be. Even knowing new PIDs would be sufficient, since I could figure a script that would take these and run ps | grep on these and give me more info while the process is running (assuming hopefully the process is still around when ps gets going)

Vasiliy Sharapov
  • 233
  • 1
  • 2
  • 8

4 Answers4

7

What do you want to know about those processes? If you can control who spawns the processes, strace -feprocess $SHELL will do.

If it's just an overview of their footprint, use process accounting (in the gnu acct package; use the lastcomm command), or higher-level tools like atop's logger mode. In the future, tools like trace and uprobes will be helpful to get detailed info out of the kernel.

Tobu
  • 4,367
  • 1
  • 23
  • 31
1

auditd?

http://linux.die.net/man/8/auditctl

cheeseprocedure
  • 199
  • 2
1

Snoopy might be the right tool for your use case.

If you need simple logger and you are NOT looking for security/auditing solution, then Snoopy might be it.

Disclosure: Snoopy maintainer here.

Bostjan Skufca Jese
  • 87
  • 2
0

You should use lastcomm, but as my Kernel is not build with Process Accounting, my only option was top to find a process which permanently woke up my USB HDD. Finally I came to this command:

top -b -c -d 5 > /tmp/top.log

It executes top every 5 seconds (-d 5) with the full list of all processes (-b) and full command (-c) and writes it to the file /tmp/top.log (>).

After I saw the disk spinning I stopped the logging, checked all output in the current timeframe and finally found the culprit.

top allows -d 0, which "causes (nearly) continuous updates", but continous writing to a log file produces huge load, so be warned.

If you don't want to write to a drive, you could use tmpfs to create a ramdisk, so the log files is written to the RAM.

mgutt
  • 459
  • 6
  • 22
  • unlike audit, this yields entirely unpredictable results for short-running processes (and for this example purpose, is an insult to the amount of work spent on `blktrace` & `fanotify` interfaces) – anx Oct 17 '20 at 01:50
  • Yes it will, but this was my only option as `lastcomm` failed because my linux kernel has not accounting enabled and maybe it helps other users as well. – mgutt Oct 17 '20 at 09:09