Is it possible by any means to brute force momentally pause the execution of an external program? Or something that archieves a similar effect.
I've seen this beforce, a 3rd party software that once came with my Asus laptop, however Im courious on how they managed it.
You can send signals to process. Depending on your operating system, they mean different things. A program which catches a signal may terminate, sleep or continue.
Here is a manual about signals: http://www.cs.cf.ac.uk/Dave/C/node24.html
In short:
Use kill (dont be scared, the functions is just called kill and wont terminate anything on its own) to send a signal to a known process id. You can get process ids in linux with ps aux in terminal. This Linux signal looks promising for you:
SIGCONT 19 /* continue a stopped process */
int kill(int pid, int signal)
a system call that send a signal to a process, pid. If pid is greater than zero, the signal is sent to the process whose process ID is equal to pid. If pid is 0, the signal is sent to all processes, except system processes.
I don't know much about Windows SIGNAL Codes, but it should work similar. Don't know if they are handling the signal codes different then Linux.
There is also: signal (int number, functionPointer) to call a function, if your programm gets a specific signal.
I don't know about bruteforce, but you can probably just set a debug break in a program and that would pause it.
Related
I have a PID of a LINX process (obtained through 'linxstat' command) that I want to send a LINX signal (http://linx.sourceforge.net/linxdoc/doc/html/linx.7.html) to:
Cmn::Ipc<ASig> sig(A_SIG);
sig->a = 10;
sig->b = 20;
sig.send(PID);
Now, before I send the LINX signal to the PID, I want to make sure that the PID exists and is still running (making sure the process hasn't crashed). If the PID does not exist, then I'll send it to another common process which has a PID of 0 and this process can handle any type of signal. Is there a way to check if the PID exists in C++? If yes, what is the LINX API for it?
I want to be able to do this without having to know the process name and with just the PID of the process.
Anywhere between the code that gets the PID, performs the PID check and sends a signal target process can exit and the new unrelated process with the same PID can spawn as range of PID numbers is limited and they are reused over time. So I think it is not possible to achieve what you want with just PID.
You can send signal 0 first:
kill(2):
If sig is 0, then no signal is sent, but error checking is still
performed; this can be used to check for the existence of
a process ID or process group ID.
But it's probably pointless. Moreover, this kind of pid-based access is rather race-condition prone unless you're the parent of the process (in which case you always know whether or not it ended and whether or not you've reaped it).
No matter what you do to check that it is currently running, there's no guarantee that it won't crash between the time you check and the time you send the signal - or, between the time you send the signal and the time it arrives. So, just send the signal and find a way to deal with the fact that the process may not be there when it arrives. In extreme cases the process may even die and its PID be re-used before the signal arrives - have fun dealing with that..
In my process I need to start/restart another process.
Currently I use a thread with a tiny stack size and the following code:
void startAndMonitorA()
{
while(true)
{
system("myProcess");
LOG("myProcess crashed");
usleep(1000 * 1000);
}
}
I feel like that's not best practice. I have no idea about the resources the std::system() call is blocking or wasting. I'm on an embedded Linux - so in general I try to care about resources.
One problematic piece is restarting immediately: if the child process fails to start that is going to cause 100% CPU usage. It may be a transient error in the child process (e.g. cannot connect to a server). It may be a good idea to add a least one second pause before trying to restart.
What system call does on Linux is:
Sets up signals SIGINT and SIGQUIT to be ignored.
Blocks signal SIGCHLD.
fork()
Child process calls exec() shell, passing the command line to the shell.
Parent process calls waitpid() that blocks the thread till the child process terminates.
Parent process restores its signal dispositions.
If you were to re-implement the functionality of system you would probably omit step 5 (along with steps 1, 2 and 6) to avoid blocking the thread and rely on SIGCHLD to get notified when the child process has terminated and needs to be restarted.
In other words, the bare minimum would be to set up a signal handler for SIGCHLD and call fork and exec.
The code as shown would be adequate for most circumstances. If you really care about resource usage, you should be aware that you are starting (and keeping around) a thread for each process you are monitoring. If your program has an event loop anyway, that kind of thing can be avoided at the cost of some additional effort (and an increase in complexity).
Implementing this would entail the following:
Instead of calling system(), use fork() and exec() to start the external program. Store its PID in a global table.
Set a SIGCHLD handler that notifies the event loop of the exit of a child, e.g. by writing a byte to a pipe monitored by the event loop.
When a child exits, run waitpid with the WNOHANG flag in a loop that runs for as long as there are children to reap. waitpid() will return the PID of the child that exited, so that you know to remove its PID from the table, and to schedule a timeout that restarts it.
I have written a c++ program which has a infinite loop. I want to run this program as a daemon (or service) in linux.
I want to communicate with this running daemon from outside of program (for example console or another program).
I read about signal handling in c++ and apparently there are some predefined signals. Is there any way to send your own signal to the running program?
Signals are most probably not what you really want to communicate with a demon process, unless you want to terminate it in a specific manner.
Also no, you can't define your own arbitrary signal numbers, as the operating system needs to know how they are sent to the process. As mentioned in my comment there are the SIGUSR1 and SIGUSR2 were intended for user defined signalling purposes.
The easiest way to let an external process communicate with a demon process, is to give it a configuration file, and let the demon watch for changes using the inotify() interface.
This technique is also used by many system demons already.
You can use kill(pid, signal) from one process to send signal to another. Sending SIGKILL will violently and instantly terminate your process.
Signals are limited to what they express - and you can find that out by accessing page 7 of signal manual. Some signals can be ignored/handled/blocked while others cannot.
If you want true custom inter-process communication you should use pipes or even sockets (bad practice). This way, you would have to define your own protocol and you can do a lot more than with signals.
Here's a tutorial on how to use named pipes to send data to running processes: http://www.linuxjournal.com/content/using-named-pipes-fifos-bash.
Sometimes when I am debugging I get message like this.
Program received signal SIG44, Real-time event 44.
What does it means?
Thank you.
EDIT :
Platform is linux
A signal is a message sent by the kernel to a process in order to notify the process that event of some kind has occurred in the system.
Usual signals on linux are for example SIGINT (value 2, interrupt from keyboard) or SIGKILL ( value 9, kill a program).
Signals are received either when the kernel detects a system event (like division by zero is SIGFPE, value 8) or when a process invokes the kill() function to explicitly tell the kernel to send a signal to a process (or to the process itself that called the kill() ).
A signal can often be caught by the process in order to do something.
So to answer to your question, the code is most likely calling the kill() function and sending it a signal with value 44 when something happens. Since you are getting that message, it means that the process has received the signal and is going to exit or do what is written in the code in case that signal comes.
Unlike standard signals, real-time
signals have no predefined meanings:
the entire set of real-time signals
can be used for application-defined
purposes. (Note, however, that the
LinuxThreads implementation uses the
first three real-time signals.)
Source for the quote here
The GNU C++ library uses SIG44 to awaken sleeping threads when signalling condition variables.
I am invoking several processes in my main and I can get the pid of that processes. Now I want to wait until all this processes have been finished and then clear the shared memory block from my parent process. Also if any of the process not finished and segfaulted I want to kill that process. So how to check from the pid of processes in my parent process code that a process is finished without any error or it gave broke down becoz of runtime error or any other cause, so that I can kill that process.
Also what if I want to see the status of some other process which is not a child process but its pid is known.
Code is appreciated( I am not looking for script but code ).
Look into waitpid(2) with WNOHANG option. Check the "fate" of the process with macros in the manual page, especially WIFSIGNALED().
Also, segfaulted process is already dead (unless SIGSEGV is specifically handled by the process, which is usually not a good idea.)
From your updates, it looks like you also want to check on other processes, which are not children of your current process.
You can look at /proc/{pid}/status to get an overview of what a process is currently doing, its either going to be:
Running
Stopped
Sleeping
Disk (D) sleep (i/o bound, uninterruptable)
Zombie
However, once a process dies (fully, unless zombied) so does its entry in /proc. There's no way to tell if it exited successfully, segfaulted, caught a signal that could not be handled, or failed to handle a signal that could be handled. Not unless its parent logs that information somewhere.
It sounds like your writing a watchdog for other processes that you did not start, rather than keeping track of child processes.
If a program segfaults, you won't need to kill it. It's dead already.
Use the wait and waitpid calls to wait for children to finish and check the status for some idea of how they exiting. See here for details on how to use these functions. Note especially the WIFSIGNALED and WTERMSIG macros.
waitpid() from SIGCHLD handler to catch the moment when application terminates itself. Note that if you start multiple processes you have to loop on waitpid() with WNOHANG until it returns 0.
kill() with signal 0 to check whether the process is still running. IIRC zombies still qualify as processes thus you have to have proper SIGCHLD handler for that to work.