I am trying to create an application in userspace that sets affinity of processes. I would like the program to be triggered immediately every time a new pid/tid is spawned by the kernel. I am attempting to write to a file node under /proc from the do_fork() method in the kernel but I feel that it may have too much overhead.
Does anyone know any alternatives to detect a new process creation immediately after it is spawned?
If monitoring do_fork() is the way to go, would a call back to an userspace program via a system call be faster that using a fs node to communicate?
Forkstat is a program that logs process fork() [among other things]
Install it:
$ sudo apt-get install forkstat
Use it to log "fork" events:
$ forkstat -e fork
Use a socket with NETLINK_CONNECTOR. The kernel will tell you about process events, including fork()s and exec()s. You must have CONFIG_CONNECTOR and CONFIG_PROC_EVENTS enabled in your kernel.
Here's a related question with more details:
Detect launching of programs on Linux platform
For a complete socket NETLINK_CONNECTOR example, see:
http://bewareofgeek.livejournal.com/2945.html
As an aside, Inotify doesn't work. It will not work on /proc/ to detect new processes:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722
execsnoop can be a good alternative to show new processes and arguments.
Related
How can I trace the threads / systems calls in a process if the process id is known?
For system calls, you can use strace(1) and it supports attaching to live processes. You just need to figure out the process/thread id.
In linux we create a process using fork and exec ant while in windows we use createprocess .My teacher told that linux method of creating process is more robust than windows why?
Fork & exec are direct calls to the kernel whereas createprocess goes through window api to access kernel.
There might be more various reasons but this is what I have on top of my mind :)
We have about 40 computers running identical hardware and software. They all run Ubuntu 11.10. They all have just one user account to log in. The .profile file is set up to launch a daemon process. The code for the daemon is written in C.
Once in a few weeks, we get a report that the daemon is no longer running. This does not happen on all computers but just one or two. We cannot reproduce the problem consistently.
Looking at the code, the application quits when it receives either SIGHUP or SIGTERM.
As I understand, SIGHUP is generated when a user logs off. In our case, the user never logs off. I am wondering if it is possible that SIGHUP could have been generated for some other reason. Any other thought would be appreciated.
Well, there are a couple of things to note about SIGHUP. Firstly, its origin is from the concept of a hang-up, i.e. loss of connection to a console over something like a modem. In modern parlance this generally means it has lost its controlling tty. Unless you've taken care to detach from your tty, any program started in a given terminal will receive a SIGHUP when the terminal is closed. See here for details on how to do this in your program. Other options include:
running your program inside screen or tmux
run your program with nohup or some other daemonising framework
The other possibility is something is deliberately sending your process a SIGHUP which by "tradition" is often used to signal a process that it should re-read its configuration.
Signals can be sent using kill utility or kill syscall.
Of course, you can try and find out who is sending that signal or disconnecting your terminals or network connections, but there is simpler practical way to fix your problem.
When code is supposed to run as a daemon, but really isn't (just like yours), there is a wrapper that can turn any program into daemon. Surprise - this wrapper is called daemon! It has lots of options, probably most importantly for you, option to automatically restart your utility should it ever die for any reason.
If this command is not installed on your Ubuntu, just sudo apt-get install daemon, and man daemon to get started.
Are there any watchdog tools or libraries on Linux for the following purpose? I would like to build a watchdog executable which starts 2 processes and restarts them if:
processes crash
processes become unresponsive (e.g. hang for some reason)
Internet search found watchdog.c but I am not sure if that can be used for my purposes, it looks pretty low level.
I could run my processes as init programs (daemons) as suggested here, but I am not sure if Linux would then recognize that the process is hanging (e.g. due to a deadlock)
We use monit here: http://mmonit.com/monit/ it will let you do the restart thing it is also highly customizable regarding how to check and how to react via scripts
Is there a standard linux/unix pattern for communicating with long running process?
For example, I have few hundred process, written in c++, and running on various machines and I would like to send them a command like reload configuration, start, stop etc via shell scripts.
Signals.
If you're trying to trigger simple actions like the start/stop/reload configuration as you've described, the most common method is to use signals.
From your shell script you can use the kill command to send a specific signal to a specific process.
Within your process you would implement one or more signal handlers. The signal handler(s) are registered to receive one or more signals by using the signal() function, or the sigaction() function.
Conventionally SIGHUP is used to trigger a reload of configuration. SIGSTOP and SIGCONT may be appropriate for pausing and resuming.
man 7 signal will show you a complete list of available signals to choose from.
If you need to trigger more complex actions you can create a named pipe. Have your process create the pipe and, from your shell script, just echo commands to it.
Since you also care about remote processes, and assuming you can modify the source code of all your programs, you could consider some way to communicate with them:
defining your own small textual protocol, and have each process listening on some socket or some named pipe. You probably would need some multiplexing syscall like poll
use existing libraries and tools like MPI, Corba, or perhaps D-Bus or ONC/RPC/XDR
change the configuration files of your application, and have signal conventions, e.g. catch SIGHUP to reload the configuration, and SIGTERM to properly terminate it (but there is no way to send a signal remotely; you'll need e.g. to ssh some kill command).