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
Related
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.
I'm trying to write a shell in C.
And now i want to make shell catch the signal of suspend, and suspend the running process, but i am not sure which function can return the pid of running process. Currently, i know proc/pid has status info of process, but I don't think scanning all processes to find running status is a good idea. So anyone can give me a hint?
Also I don't know if waitpid works for me, but from my understanding, waitpid is supposed to keep waiting until the child process stops, and this will never tell me if it's still running, am I right?
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.
Not long ago, I wondered about the question: why are all processes killed when you close a terminal on Linux, and not passed to the "init" process (with pid 1)?
Because, all child processes are adopted by "init" process after termination of the parent.
Please, help me understand difference and the errors in my reasoning.
And also:
If it's possible, then can we use a system call to stop this happening? I think, that for this the programs need use setsid(), but in practice it's not correct.
As explained by cnicutar, it's due to the SIGHUP sent to all processes in the process group associated with the controlling terminal. You may either install a handler for this signal or ignore it completely. For arbitrary programs, you can start them with the nohup utility designed for this purpose.
You can also place the process in a new process group without a controlling terminal.
why on close terminal on linux all his processes will terminated, but
not passed to "init" process (with pid 1)
The processes are losing their controlling terminal so the kernel sends them a SIGHUP. The default action of SIGHUP is to terminate the process.
i think this will help you to understand
http://www.digipedia.pl/usenet/thread/18802/10189/
I am creating a GTK application in C. I am creating a child process using fork and then replacing it with execve("crawler",arg,env); which crawls my home directory and stores all the filenames in a file.
Now, this child process takes some time (about 2-5 minutes).
In the mean time, when this child process is running, the main GTK parent program is waiting.
But when the child process is running, after some time, the GTK application hangs.
I have tried gdk_thread_enter()/leave() in my main function.
But still I am the application is hanging.
Please, point out a mistake if any or else suggest any modification.
execve does not create a child process, it replaces the current process with the child. Are you sure you used fork() first, and then execve() from within the child?
EDIT since you're already using fork/execve, perhaps the child process is still interacting with Gtk somehow. Best to use Glib/Gtk+-specific functions for invoking the crawler -- try, for instance, g_spawn_command_line_async
If what you mean by "when this child process is running, the main GTK parent program is waiting" is that your code executes a wait(), waitid(), waitpid() in its main thread, then the app will indeed suspend execution until a child terminates (unless you've selected NOHANG option).
If your Gtk app doesn't need to coordinate further with your crawler program, just use the previously-mentioned
g_spawn_command_line_async routine, and do not set G_SPAWN_DO_NOT_REAP_CHILD. If you do need to coordinate, you could set that flag, and create a GChildWatch source, or perhaps could use one of the g_spawn pipe routines.
As I interpret gdk_thread_enter()/leave(), they are locking or unlocking threading, rather than running or stopping new threads. Gtk callbacks run in the main thread, so as indicated above, a blocking waitpid() in a callback will hang the Gtk app. A non-blocking waitpid() in a timer callback (eg) is not a problem, however.