6

I Would like to capture the process entry, exit and maintain a log for the entire system (probably a daemon process).

One approach was to read /proc file system periodically and maintain the list, as I do not see the possibility to register inotify for /proc. Also, for desktop applications, I could get the help of dbus, and whenever client registers to desktop, I can capture.

But for non-desktop applications, I don't know how to go ahead apart from reading /proc periodically.

Kindly provide suggestions.

Sangeeth Saravanaraj
  • 16,027
  • 21
  • 69
  • 98
Whoami
  • 13,930
  • 19
  • 84
  • 140

4 Answers4

3

You mentioned /proc, so I'm going to assume you've got a linux system there.

Install the acct package. The lastcomm command shows all processes executed and their run duration, which is what you're asking for. Have your program "tail" /var/log/account/pacct (you'll find its structure described in acct(5)) and voila. It's just notification on termination, though. To detect start-ups, you'll need to dig through the system process table periodically, if that's what you really need.

Andrew Beals
  • 1,177
  • 8
  • 18
  • +1 for the fact that acct is mentioned here. It is an implementation of what is called Process Accounting (http://www.faqs.org/docs/Linux-mini/Process-Accounting.html) – cateof Jan 11 '12 at 16:27
2

Maybe the safer way to move is to create a SuperProcess that acts as a parent and forks children. Everytime a child process stops the father can find it. That is just a thought in case that architecture fits your needs.

Of course, if the parent process is not doable then you must go to the kernel.

cateof
  • 6,608
  • 25
  • 79
  • 153
1

If you want to log really all process entry and exits, you'll need to hook into kernel. Which means modifying the kernel or at least writing a kernel module. The "linux security modules" will certainly allow hooking into entry, but I am not sure whether it's possible to hook into exit.

If you can live with occasional exit slipping past (if the binary is linked statically or somehow avoids your environment setting), there is a simple option by preloading a library.

Linux dynamic linker has a feature, that if environment variable LD_PRELOAD (see this question) names a shared library, it will force-load that library into the starting process. So you can create a library, that will in it's static initialization tell the daemon that a process has started and do it so that the process will find out when the process exits.

Static initialization is easiest done by creating a global object with constructor in C++. The dynamic linker will ensure the static constructor will run when the library is loaded.

It will also try to make the corresponding destructor to run when the process exits, so you could simply log the process in the constructor and destructor. But it won't work if the process dies of signal 9 (KILL) and I am not sure what other signals will do.

So instead you should have a daemon and in the constructor tell the daemon about process start and make sure it will notice when the process exits on it's own. One option that comes to mind is opening a unix-domain socket to the daemon and leave it open. Kernel will close it when the process dies and the daemon will notice. You should take some precautions to use high descriptor number for the socket, since some processes may assume the low descriptor numbers (3, 4, 5) are free and dup2 to them. And don't forget to allow more filedescriptors for the daemon and for the system in general.

Note that just polling the /proc filesystem you would probably miss the great number of processes that only live for split second. There are really many of them on unix.

Community
  • 1
  • 1
Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
0

Here is an outline of the solution that we came up with.

We created a program that read a configuration file of all possible applications that the system is able to monitor. This program read the configuration file and through a command line interface you was able to start or stop programs. The program itself stored a table in shared memory that marked applications as running or not. A interface that anybody could access could get the status of these programs. This program also had an alarm system that could either email/page or set off an alarm.

This solution does not require any changes to the kernel and is therefore a less painful solution.

Hope this helps.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127