1

Suppose the specific process is a long-running background process A. I wanted to execute a bash script command/script hooks for process A right after process A is started, for example getting its pid and doing something with it. The problem with my use case is that I don't have control over when/how process A is started, and I can't alter process A to generate pidfile; hence the hook idea.

Currently, process A can be run multiple times so there can be multiple pids associated to process A. The script hook should be run on every instance of process A, not just the first run.

I have tried using cron and pgrep to get all the instances of process A. However, there's 60-second latency with this approach since it is the shortest polling interval time with cron.

My questions:

  1. What are my options for near real-time notification (< 5-sec latency is acceptable, the lower the better) whenever new process A is started AND execute the bash hook for process A reliably?
  2. Is running an infinite while loop + pgrep in the bg with lower latency (eg: 1-5 secs sleep) a safe option?
  3. Since inotify exists for file events, is there any similar mechanism for listening (+ running cmd hook) to a specific process event (eg: started/killed/proc status change)?

Thanks!

9
  • 1
    What starts the "long running backgtound process A"? Are you an administrator on the machine?
    – icarus
    Jan 29, 2022 at 20:08
  • Once you have the PID, what will you do with "process A"? Will you it once per "process A", or repeatedly. Do you have the support of your SysAdmin AND the owner of "process A"? If we help, will it turn out to have been criminal?
    – waltinator
    Jan 29, 2022 at 21:44
  • @icarus imagine a client-server arch where multiple clients can run arbitrary programs on the server. The server don't know when the program will be run by the client (nor what programs will be run by them), but when a certain program is run the server wants to run additional scripts
    – deka108
    Jan 31, 2022 at 1:42
  • @waltinator No, we will not modify Process A. Instead, we have another secure process running on the server that we control (eg: Process B) that provides data for other processes. In order for any process to access the data, they need to be authenticated with Process B which utilizes the proc PID. So in this case, we want to authenticate all instances of Process A runs (cos they can be run multiple times with different PIDs) with Process B.
    – deka108
    Jan 31, 2022 at 1:50
  • @icarus Yes, we're the admin of the server machine (where Process A is run) but not the admin of the client machines. Process A is a process that we can't modify and can't know when they start as it is triggered from the client-side, but the server has control over stopping them.
    – deka108
    Jan 31, 2022 at 1:57

1 Answer 1

1

The only reliable solution is to arrange to run the program via a wrapper script. There are many different ways to do that, and it's unusual for none of them to apply.

  • Configure or modify the program(s) that call this program to run your wrapper instead.
  • Put a wrapper by the same name ahead of the real program in the $PATH.
  • Rename the program and give the wrapper its original name.

This approach guarantees that your wrapper will run, and it gets the opportunity to prepare before running the real program if necessary. The wrapper also gets the ability to be the parent process of the real program, which lets it reliably be notified when it dies and obtain its exit status.

You can use LoggedFS to monitor events on a filesystem. See LoggedFS configuration file syntax for documentation on its configuration file. Point loggedfs to the directory containing the executable. Note that you need to own it or run loggedfs as root. Each time a file is executed, there is an open event, and you get the PID of the process. Note that there is also an open event if the file is opened for reading; I don't think you can distinguish execute events specifically with LoggedFS alone. When the process exits, there is a release event. Note that by the time your monitoring code runs, the process might have already died.

Under Linux, you can use inotifywait to wait for an access or close_nowrite event on the executable, e.g. inotifywait -m -e access,close_nowrite --format=%e /bin/ls. There is an access event whenever the file is executed and a close_nowrite when the process dies. You can't get the process ID that way, so you'll then have to find out which processes have the file open (e.g. with fuser or lsof) and then filter the ones that are executing the file.

Linux also has a more precise facility that lets you monitor events such as the execution of a specific file and reports the PID that caused the event: the audit subsystem. See Is there an easy way to log all commands executed, including command line arguments?. You can then use audispd to run a custom program when the audit event occurs. All this requires being root, though, and if you were root then presumably you could replace the executable and you wouldn't need this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .