I have main program from which I create two threads using pthread_create(). In one thread, I call
Thread I
{
...
system ("binary application");
}
System() internally forks a child process. How can I kill that " binary application" from main program??
That's not directly supported.
You need the PID to kill a process, and system() is designed for the synchronous execution of some command — it doesn't expose the PID of the invoked command. Indeed, system() might spawn several PIDs, several generations of descendants, probably /bin/sh and then your binary-application.
How would you kill the binary-application from an external process (not a thread, a completely external process)? However you'd do that might be how your killing thread can get the PID.
It's probably easier to set an alarm on the command, or instead call fork() (which gives you the PID) and exec() in your own code. In any case, system() in a multithreaded program can be tricky, so take care.
Related
I want to use system() to execute a cmd.
If the cmd takes a long time like ping, it will block main thread.
So I want to create a child thread to handle it. In this child thread the system() will be invoked.
As we all know, the system() will fork a child process.
I'm NOT sure whether any problem or side effect when the system() is invoked in a child thread.
system() is marked as thread-safe by Linux/glibc documentation. See the man page. But with a caveat:
According to POSIX.1, it is unspecified whether handlers registered
using pthread_atfork(3) are called during the execution of system().
In the glibc implementation, such handlers are not called.
From what you described, you probably don't have atfork handlers, so it's fine.
I want to use system() to execute a cmd. If the cmd takes a long time like ping, it will block main thread.
However, if the sole purpose of using a separate thread is to run a command, why not fork(2) directly and let it child process exec command?
The main process can still carry on and can check whether the child process completed (e.g., using waitpid with WNOHANG).
This would be cleaner in my opinion and avoids the fork+threads complexity.
I have a C program running on Linux 3.12. This program spawns several child processes. One of these processes spawns a thread that runs for a bit then terminates. While this child process is running it performs an epoll_wait(). Periodically, the epoll_wait returns with an EINTR error. I setup the child process to catch the signal doing this interruption and found it is a signal 17, which, according to everything I have read is a SIGCHLD. Thing is, the thread this child process spawned is still running. It did not terminate. I also thought that threads do not generate a SIGCHLD on termination.
Any thoughts on why my process may be getting a signal 17?
The answer is a call to system(). This function in the code spawns a process to execute the shell command being passed in. The thread was calling system() to run some shell commands. When they finished the processes that was spawned ended and generated the SIGCHLD.
I want to write a 'zombie creator' and 'zombie terminator'. Main point is that I want to create zombies in one part and terminate them in other part of code. I'm using C.
Example:
create_zombie(); //let's say it's a spawn, using fork etc.
/* a houndred lines below */
kill_zombie(PID); // PID is determinated by user, I want to leave him the choice
I know how to do this using fork(), if .. else, but that's not the point. I'm looking for some kind of remote control. Is that possible? Sleeping him for a long time could be a solution?
I'm assuming Linux, but the process should be similar on other operating systems. You want to look into the kill() function declared typically declared in the signal.h header file. This will allow you to send a signal to a specific PID from your zombie killer. The easiest approach would be to send your zombie process a kill signal (SIGKILL). SIGKILL cannot be caught or ignored, and immediately kill a process dead.
If you need to do some cleanup in your zombie process, you can create a signal handler with the signal() function. This will allow you to specify a function to call when a process receives a signal. This function would implement your cleanup code and then exit().
On linux, your shell should have a kill command that mimics the functionality of kill(). The syntax is typically kill -s 9 PID. This will send a SIGKILL (signal number 9) to the process PID.
I hope this answer nudges you in the proper direction.
When you fork a process, fork returns 0 in the child process and the child's process id in the parent. You can save them in an array, write them to a file, or write them to a pipe and don't "uncap" the other end until you need it.
I'm writting a C program that launches another program using the system() function. I'd want to know if there is a possible way to kill the program that is launched, if the main program is killed. I'm programming it for a Linux machine.
Example:
/* foo.c */
int main()
{
system("./blah");
return 0;
}
blah does whatever has to do. If I kill foo, blah is still running.
Is there any way to make foo to kill blah when it dies ?
You'll need to work with signal handling to know when someone/something is trying to kill your application, read the below documentation for further information.
linuxjournal.com - The Linux Signal Model
Besides that you'll need to know the process id of your spawned child process. For this I'd recommend to use something more sophisticated than system to fire up your launched process.
yolinux.com - Fork, Exec and Process control
You'll also have to know how to kill the spawned child (using it's pid).
pubs.opengroup.org - functions: kill
I am working on a multithreaded process that forks to execute another process. Sometimes, the fork may error if the execution file does not exist. Since this process has multiple threads running prior to fork I have a couple questions:
Are threads copied over to the forked process.
What is the best practice to handling an error from fork with a multithreaded process. For example:
/* in a multithreaded process */
pid = fork();
if(pid == 0)
{
execlp(filename, filename, NULL);
fprintf(stderr, "filename doesn't exist");
/* what do i do here if there's multiple threads running
from the fork? */
exit(-1);
}
Well, the fork doesn't error if the executable file doesn't exist. The exec errors in that case. But, to your actual question, POSIX states that fork creates a new process with a single thread, a copy of the thread that called fork. See here for details:
A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources.
Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.
So what you have is okay, if a little sparse :-)
A single thread will be running in the child and, if you cannot exec another program, log a message and exit.
And, in the rationale section, it explains why it was done that way:
There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.
The general problem with making fork() work in a multi-threaded world is what to do with all of the threads. There are two alternatives. One is to copy all of the threads into the new process. This causes the programmer or implementation to deal with threads that are suspended on system calls or that might be about to execute system calls that should not be executed in the new process. The other alternative is to copy only the thread that calls fork(). This creates the difficulty that the state of process-local resources is usually held in process memory. If a thread that is not calling fork() holds a resource, that resource is never released in the child process because the thread whose job it is to release the resource does not exist in the child process.
When a programmer is writing a multi-threaded program, the first described use of fork(), creating new threads in the same program, is provided by the pthread_create() function. The fork() function is thus used only to run new programs, and the effects of calling functions that require certain resources between the call to fork() and the call to an exec function are undefined.