How does GDB achieves the feat of attaching itself to a running procesS?
I need a similar capability, where i can issue CLI commands to a running process. For example, i can query the process internal state such as show total_messages_processed? How can i build support for issuing commands to a running process under linux?
Is there a library that can provide CLI communication abilities to a running process and can be extended for custom commands?
The process itself is written in c++
GDB doesn't use the CLI to communicate with its debugee; it uses the ptrace system call / API.
CLI means "command-line interface". The simplest form of communication between processes is stdin / stdout. This is achieved through pipes. For example:
ps -ef | grep 'httpd'
The standard output of ps (which will be a process listing) is connected to the standard input of grep, who will process that process listing output line-by-line.
Are you writing both programs, or you want to communicate with an already-existing process? I have no idea what "show total_messages_processed" means without context.
If you simply want the program to communicate some status, a good approach is that which dd takes: Sending the process the SIGUSR1 signal causes it to dump out its current stats to stderr and continue processing:
$ dd if=/dev/zero of=/dev/null&
[1] 19716
$ pid=$!
$ kill -usr1 $pid
$ 10838746+0 records in
10838746+0 records out
5549437952 bytes (5.5 GB) copied, 9.8995 s, 561 MB/s
Did you consider using AF_UNIX sockets in your process? or D-bus? or make it an HTTP server (e.g. using libonion or libmicrohttpd), perhaps for SOAP, or RCP/XDR
Read some books on Advanced Linux Programming, or Advanced Unix Programming; you surely want to use (perhaps indirectly) some multiplexing syscall like poll(2) perhaps above some event libary like libev. Maybe you want to dedicate a thread for that.
We cannot tell more without knowing what kind of process are you thinking of. You may have to redesign some part of it. If the process is some traditional compute-intensive thing it is not the same as a SMTP server process. In particular, if you have some event loop in the process, use & extend it for monitoring purposes. If you don't have any event loop (e.g. in a traditional number crunching "batch" application) you may need to add one.
In this case I'd suggest 'fork', which splits the currently running process into two. The parent process would read stdin, process the commands and be able to handle all memory that is shared between the two processes. One could theoretically even skip advanced forms of interprocess communication: locks, mutexes, semaphores, signals, sockets or pipes -- but be prepared that the child process has not necessarily written it's state to memory but keeps it in registers.
At fork Operating System makes a copy of the process local variables, after which each process have their own internal state -- thus the easiest method for passing data would be to allocate "shared memory".
One can also write a signal handler to the child process, that goes to sleep/wait state and exits only on another signal -- in that way one can have more time to inspect the child processes internal state. The main rationale for this kind of approach is that one doesn't have to make the process under debugging aware of being debugged: the parent and child processes share the same code base and it's enough for the parent process to implement necessary output methods (formatting to screen?) and serializing the data etc.
Related
I am trying to run multiple command in ubuntu using c++ code at the same time.
I used system() call to run multiple command but the problem with system() call is it invoke only one command at a time and rest commands are in waiting.
below I wrote my sample code, may this help you to get what I am trying to do.
major thing is I want to run all these command at a time not one by one. Please help me.
Thanks in advance.
main()
{
string command[3];
command[0]= "ls -l";
command[1]="ls";
command[2]="cat main.cpp";
for(int i=0;i<3;i++){
system(command[i].c_str());
}
}
You should read Advanced Linux Programming (a bit old, but freely available). You probably want (in the traditional way, like most shells do):
perhaps catch SIGCHLD (set the signal handler before fork, see signal(7) & signal-safety(7)...)
call fork(2) to create a new process. Be sure to check all three cases (failure with a negative returned pid_t, child with a 0 pid_t, parent with a positive pid_t). If you want to communicate with that process, use pipe(2) (read about pipe(7)...) before the fork.
in the child process, close some useless file descriptors, then run some exec function (or the underlying execve(2)) to run the needed program (e.g. /bin/ls)
call (in the parent, perhaps after having got a SIGCHLD) wait(2) or waitpid(2) or related functions.
This is very usual. Several chapters of Advanced Linux Programming are explaining it better.
There is no need to use threads in your case.
However, notice that the role of ls and cat could be accomplished with various system calls (listed in syscalls(2)...), notably read(2) & stat(2). You might not even need to run other processes. See also opendir(3) & readdir(3)
Perhaps (notably if you communicate with several processes thru several pipe(7)-s) you might want to have some event loop using poll(2) (or the older select(2)). Some libraries provide an event loop (notably all GUI widget libraries).
You have a few options (as always):
Use threads (C++ standard library implementation is good) to spawn multiple threads which each perform a system call then terminate. join on the thread list to wait for them all to terminate.
Use the *NIX fork command to spawn a new process, then within each child process use exec to execute the desired command (see here for an example of "getting the right string to the right child"). Parent process can use waitpid to determine when all children have finished running, in order to move on with the program.
Append "&" to each of your commands, which'll tell the shell to run each one in the background (specifically, system will start the process in the background then return, without waiting for the result). Not tried this, don't know if it'll work. You can't then wait for the call to terminate though (thanks PSkocik).
Just pointing out - if you run those 3 specific commands at the same time, you're unlikely to be able to read the output as they'll all print text to the terminal at the same time.
If you do require reading the output from within the program (though not mentioned in your question), this is relevant (although it doesn't use system).
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.
I'm using C++ and I need the equivalent of SIGCHLD for a process I'm aware of (i.e. I know it's pid), but did not spawn.
Is there a well established design pattern to listen/watch/monitor another process's lifespan when it is not your child or in your group or session?
EDIT: I am specifically trying to be aware of abnormal terminations (i.e. seg faults, signals, etc...). I would like to eavesdrop on signals the process in question receives.
I don't know if it follows a specific pattern, per se, but one technique is to have the process establish a connection to the watcher. The watcher monitors the connection, and when it becomes closed, it knows the process has shutdown.
If the watcher wants to know if the watched process is responsive or not, you can use the connection to monitor heartbeat messages that the process is obliged to provide.
If the watcher wants to know whether the watched process is making progress, the heartbeat message could provide state information that would allow the watcher to monitor that.
Different operating systems may provide different ways to achieve the same objective. For example, on Linux, the watcher could use inotify to monitor the /proc entry for that process to determine if the process is up or down. The BSD kqueue has a similar capability. The process could export its heartbeat/state into shared memory, and the watcher could use a timed wait on a semaphore to see if the data is being updated.
If the process is a third-party program, and source is not available, then you would have to resort to some method similar to inotify/kqueue, or as a last resort, poll the kernel state (similar to the way the top utility works).
I want to make an application in C or C++ which have to monitor some specific processes. How can I make it possible in C?
You said that you have tomaonitor "some specific processes". If your application started the processes, you can extract the process handles from the PROCESS_INFORMATION structure (field hProcess) you passed to the CreateProcess function. If the process you want to track has been launched in some different way, you need the process' ID (PID), and use it as third argument of OpenProcess to obtain an handle. So you can use the WaitForSingleObject or WaitForMultipleObjects functions to wait for the process completion. Optionally you can obtain the process' exit code with the GetExitCodeProcess function.
There are other ways by which an application can start a new process (e.g. by the _system() library function), but I strongly suggest to use CreateProcess directly in your code, since you can control the child process' behaviour completely (e.g. you can select the priority, pass stdin/stdout/stderr handles, decide the startup window's characteristics...).
Suggested example:
http://msdn.microsoft.com/en-us/library/ms682512%28VS.85%29.aspx
You start a process in Windows with the CreateProcess() function. It returns a HANDLE to the process in PROCESS_INFORMATION.hProcess. That handle will be signaled when the process terminates, allowing you to keep track of its lifetime. Use WaitForSingleObject() or WaitForMultipleObjects() to do so. There's a code sample available here...
Before you write your own, have you looked at Process Monitor v2.8?
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements including rich and
non-destructive filtering,
comprehensive event properties such
session IDs and user names, reliable
process information, full thread
stacks with integrated symbol support
for each operation, simultaneous
logging to a file, and much more.
Boost.Process
sample for Win32 Platform.
I have a simple c++ application that generates reports on the back end of my web app (simple LAMP setup). The problem is the back end loads a data file that takes about 1.5GB in memory. This won't scale very well if multiple users are running it simultaneously, so my thought is to split into several programs :
Program A is the main executable that is always running on the server, and always has the data loaded, and can actually run reports.
Program B is spawned from php, and makes a simple request to program A to get the info it needs, and returns the data.
So my questions are these:
What is a good mechanism for B to ask A to do something?
How should it work when A has nothing to do? I don't really want to be polling for tasks or otherwise spinning my tires.
Use a named mutex/event, basically what this does is allows one thread (process A in your case) to sit there hanging out waiting. Then process B comes along, needing something done, and signals the mutex/event this wakes up process A, and you proceed.
If you are on Microsoft :
Mutex, Event
Ipc on linux works differently, but has the same capability:
Linux Stuff
Or alternatively, for the c++ portion you can use one of the boost IPC libraries, which are multi-platform. I'm not sure what PHP has available, but it will no doubt have something equivalent.
Use TCP sockets running on localhost.
Make the C++ application a daemon.
The PHP front-end creates a persistent connection to the daemon. pfsockopen
When a request is made, the PHP sends a request to the daemon which then processes and sends it all back. PHP Sockets C++ Sockets
EDIT
Added some links for reference. I might have some really bad C code that uses sockets of interprocess communication somewhere, but nothing handy.
IPC is easy on C++, just call the POSIX C API.
But what you're asking would be much better served by a queue manager. Make the background daemon wait for a message on the queue, and the frontend PHP just add there the specifications of the task it wants processed. Some queue managers allow the result of the task to be added to the same object, or you can define a new queue for the finish messages.
One of the best known high-performance queue manager is RabbitMQ. Another one very easy to use is MemcacheQ.
Or, you could just add a table to MySQL for tasks, the background process just queries periodically for unfinished ones. This works and can be very reliable (sometimes called Ghetto queues), but break down at high tasks/second.