According to my knowledge, the child process executes first. Why the parent process was executed before the child and the parent was executed again? How did the execution process went from parent to child to parent again? And why should the pipe be closed? I tried the code without the close pipe statement and I got the same output.
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
void main(){
int P1P2[2];
int P2P1[2];
pipe(P1P2);
pipe(P2P1);
int x,y;
if(fork()){ // father
close(P1P2[0]);
close(P2P1[1]);
printf("Enter one integer:");
scanf("%d",&x);
write(P1P2[1], &x, sizeof(x));
read(P2P1[0], &y, sizeof(y));
printf("Multiplication is %d\n", y);
}
else{ // Child
close(P1P2[1]);
close(P2P1[0]);
read(P1P2[0], &x, sizeof(x));
y = x*x;
write(P2P1[1], &y, sizeof(y));
}
}
output:
abbas#abbas-VirtualBox:~/Desktop$ ./simplle
Enter one integer:4
Multiplication is 16
After calling fork, there are two processes that run independently from each other. The processor switches between them like it does with other separate processes, so you won't always get the same behavior.
If you did want the parent to wait for the child to finish, you could use waitpid.
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int main(void){
int P1P2[2];
int P2P1[2];
pipe(P1P2);
pipe(P2P1);
int x,y;
if( fork() > 0 ){ // parent
close(P1P2[0]);
close(P2P1[1]);
printf("Enter one integer:");
scanf("%d",&x);
write(P1P2[1], &x, sizeof(x)); /* (2) */
read(P2P1[0], &y, sizeof(y)); /* (3) */
printf("Multiplication is %d\n", y);
} else { // Child (or pipe error)
close(P1P2[1]);
close(P2P1[0]);
read(P1P2[0], &x, sizeof(x)); /* (1) */
y = x*x;
write(P2P1[1], &y, sizeof(y)); /* (4) */
}
}
Suppose the child is running immediately after the fork, and the parent is not. The child will block on the read at (1), waiting for data. Since there is no data, it will yield the cpu. At some point in the future, the parent will be scheduled and will execute printf, scanf and write. After the parent has written into the pipe at (2), either the child or the parent may execute in any order. Eventually, the parent will block on the read at (3) and will not be able to proceed until the child writes at (4). So the pipe works to synchronize the processes.
According to my knowledge, the child process executes first. Why the parent process was executed before the child and the parent was executed again? How did the execution process went from parent to child to parent again? And why should the pipe be closed? I tried the code without the close pipe statement and I got the same output.
Your knowledge is not correct. You don't know who is going to be scheduled first, if the parent or the child. Both cases can happen. The parent is normally free to run after the system call has checked all possible errors, while the child still has to build a complete environment to run. So it is very possible for the parent to run first.
The execution normally get's like this. The parent calls fork() which in turn switches to kernel mode. Here, the parent process (there's still no child anywhere) checks all conditions necessary to create a child process, enough resources, not trespassing of limits, etc. and if everything gets ok, then it creates a new process entry in the processes table. Once this is done, the parent kernel code has all the elements to start running a second kernel thread and starts it, to execute the second part of the fork call, while the first (the parent process) already has the return code of the system call and is ready to run (this means that the child process will be executed, not failing to do that, but it doesn't need to be immediately). From this point on, the parent process can return from kernel mode with the child pid, and continue, while the child kernel has still to build enough context to run and be scheduled. This can happen very quickly, even before the scheduler has had the time to reschedule the parent again, so the conclussion is that you don't know which one is to continue executing user code first.
In respect to your second question, the order of execution from the fork() onwards depends on so many things that is actually unpredictable. Both are different processes and execute as soon as the system allows them to proceed.
In respect to the closing of the pipes, you can do it or you cannot.... as you prefer... but a pipe works passing all the data from the writer process to the reader, until the pipe gets its last close(2) When you fork()ed, the system passed of having two pipes, with four file descriptors to have 4 (two on the parent, two on the child) with a total of eight file descriptor (four readers and four writer descriptors, two for each process) (and this means that both writers, the parent process and the child process, need to close(2) the writing side of the pipe for the readers --again, both the father and the child-- to receive the corresponding EOF indicating that the other end has closed its side) This is of no concern to you (I mean, doesn't show any difference) because you have limited your protocol to just one message in each direction, and there's no EOF condition to be waited for.... but try extending your sample code to read from the pipe until it closes it side, and you will see the difference (in that case, without having closing your writer side, your process will block waiting for input, and no input is received because the other process has closed the descritptor and the only process waiting for input is the only process that can write on it).
I'm having issues working out where a good starting point for this is,
I have made dot points on what I exactly need to do but am unsure if this is entirely possible.
I have a file that I want to run multiple instances of
I want a new ID assigned to each process for the file
I need to assign a char eg. 'A' that was given through argv[1] to a process
If there is already a process with the char given, print to stderr
So far,
what I am thinking is, having something like the function below. But i'm really not too sure,
any help would be awesomeness.
int createProcess(char *argv[]){
//argv[1] is given 'A'
//fork()
//getPID()
//assign PID to 'A'
}
I think you are looking for a combination of fork and execl. You can fork to create multiple instances and then replace one of the forked process with another process by using exec(In your case it is the same process). Through execl you can give command line arguments. You may need to use sprintf in the exec'd process and sscanf in the original process. I guess this is enough hint.
I have a file that I want to run multiple instances of
To do that you have two options :
1. You can use multiple fork() system call to duplicate new child processes and open the file in those processes.
2. You can have multiple threads in your program that open the same file.
But looking at the next three dots, fork() is the choice to go with.
I want a new ID assigned to each process for the file
When you duplicate processes using fork() each process gets its own unique process Id(pid).
I need to assign a char eg. 'A' that was given through argv[1] to a process
For this you need to use one of the many calls in the "exec" family.By using "exec"
you can also pass the command line parameters to the newly created processes.
This cannot be done by fork because fork is used to duplicate the current process, whereas if you want to create a totally new process you must use exec calls.
Edit :
In order to get the command line parameters being passed to a process, you need to
know its process id and then you can look for a directory with its name same as the pid
inside the /proc file system( not mounted on actual device ). When you find the directory
you will get the parameters passed to it in a file named "cmdline".
For more detail you can read about "/proc" file system.
You will need to create multiple forking (preferably iteratively) and index your children.* One way to do that is to let the original parent loop, and only let that process do the fork. The original parent loops k times, only creating one child process per iteration. On the created child, you do stuff only the current child process will, such as assign an identifier (such as the loop counter), perform exec, and exit after the child performs everything so it does not go to the next iteration to fork to create grandchild.
Please note that the call fork() is a syscall that causes the original process (now called parent process) to create a duplicate (called child process), as well as return an int value for the parent process only.
One thing you need to observe is that the forked processes are identical with only two exceptions: the value returned by fork() and the process pid (child usually have higher pid). The value returned on the parent is the child's PID. The value on the child process is always zero. Identifying returned value of fork() is the only way to identify it the process is a parent or child.
I have a file that I want to run multiple instances of
You may need to use a combination of fork() and exec. It is not clear which type of file you want to run. Are you reading from a file, writing from a file, or executing a file?
I want a new ID assigned to each process for the file
The PID itself is a new unique ID at the time a new process is created. However, you can use a counter so that only the parent can create multiple child processes, each with a unique ID.
I need to assign a char eg. 'A' that was given through argv[1] to a process
argv[1] is a string (char array), not a char.
If there is already a process with the char given, print to stderr
It is possible that you can keep track of all identifier chars on the original parent.
Here is some sample C code where only the parent creates the forking:
int main() {
for (int k = 1; k <= 16; k++) {
int r = fork();
if (r == 0) { // kth CHILD
printf("[%d] %d\n", getpid(), k);
exit(0);
}
else if (r > 0) {
int status;
wait(&status);
printf("[%d] P\n", getpid());
}
else return 1;
}
return 0;
}
If I understand what you want correctly is to "assign" different chars to different instances of the forked process.
You can do something like this:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]){
char chr = *argv[1];
pid_t res;
res = fork();
if (!res)
chr++;
printf("%c \n", chr);
return 0;
}
Suppose I have a process which spawns exactly one child process. Now when the parent process exits for whatever reason (normally or abnormally, by kill, ^C, assert failure or anything else) I want the child process to die. How to do that correctly?
Some similar question on stackoverflow:
(asked earlier) How can I cause a child process to exit when the parent does?
(asked later) Are child processes created with fork() automatically killed when the parent is killed?
Some similar question on stackoverflow for Windows:
How do I automatically destroy child processes in Windows?
Kill child process when parent process is killed
Child can ask kernel to deliver SIGHUP (or other signal) when parent dies by specifying option PR_SET_PDEATHSIG in prctl() syscall like this:
prctl(PR_SET_PDEATHSIG, SIGHUP);
See man 2 prctl for details.
Edit: This is Linux-only
I'm trying to solve the same problem, and since my program must run on OS X, the Linux-only solution didn't work for me.
I came to the same conclusion as the other people on this page -- there isn't a POSIX-compatible way of notifying a child when a parent dies. So I kludged up the next-best thing -- having the child poll.
When a parent process dies (for any reason) the child's parent process becomes process 1. If the child simply polls periodically, it can check if its parent is 1. If it is, the child should exit.
This isn't great, but it works, and it's easier than the TCP socket/lockfile polling solutions suggested elsewhere on this page.
I have achieved this in the past by running the "original" code in the "child" and the "spawned" code in the "parent" (that is: you reverse the usual sense of the test after fork()). Then trap SIGCHLD in the "spawned" code...
May not be possible in your case, but cute when it works.
Under Linux, you can install a parent death signal in the child, e.g.:
#include <sys/prctl.h> // prctl(), PR_SET_PDEATHSIG
#include <signal.h> // signals
#include <unistd.h> // fork()
#include <stdio.h> // perror()
// ...
pid_t ppid_before_fork = getpid();
pid_t pid = fork();
if (pid == -1) { perror(0); exit(1); }
if (pid) {
; // continue parent execution
} else {
int r = prctl(PR_SET_PDEATHSIG, SIGTERM);
if (r == -1) { perror(0); exit(1); }
// test in case the original parent exited just
// before the prctl() call
if (getppid() != ppid_before_fork)
exit(1);
// continue child execution ...
Note that storing the parent process id before the fork and testing it in the child after prctl() eliminates a race condition between prctl() and the exit of the process that called the child.
Also note that the parent death signal of the child is cleared in newly created children of its own. It is not affected by an execve().
That test can be simplified if we are certain that the system process who is in charge of adopting all orphans has PID 1:
pid_t pid = fork();
if (pid == -1) { perror(0); exit(1); }
if (pid) {
; // continue parent execution
} else {
int r = prctl(PR_SET_PDEATHSIG, SIGTERM);
if (r == -1) { perror(0); exit(1); }
// test in case the original parent exited just
// before the prctl() call
if (getppid() == 1)
exit(1);
// continue child execution ...
Relying on that system process being init and having PID 1 isn't portable, though. POSIX.1-2008 specifies:
The parent process ID of all of the existing child processes and zombie processes of the calling process shall be set to the process ID of an implementation-defined system process. That is, these processes shall be inherited by a special system process.
Traditionally, the system process adopting all orphans is PID 1, i.e. init - which is the ancestor of all processes.
On modern systems like Linux or FreeBSD another process might have that role. For example, on Linux, a process can call prctl(PR_SET_CHILD_SUBREAPER, 1) to establish itself as system process that inherits all orphans of any of its descendants (cf. an example on Fedora 25).
If you're unable to modify the child process, you can try something like the following:
int pipes[2];
pipe(pipes)
if (fork() == 0) {
close(pipes[1]); /* Close the writer end in the child*/
dup2(pipes[0], STDIN_FILENO); /* Use reader end as stdin (fixed per maxschlepzig */
exec("sh -c 'set -o monitor; child_process & read dummy; kill %1'")
}
close(pipes[0]); /* Close the reader end in the parent */
This runs the child from within a shell process with job control enabled. The child process is spawned in the background. The shell waits for a newline (or an EOF) then kills the child.
When the parent dies--no matter what the reason--it will close its end of the pipe. The child shell will get an EOF from the read and proceed to kill the backgrounded child process.
For completeness sake. On macOS you can use kqueue:
void noteProcDeath(
CFFileDescriptorRef fdref,
CFOptionFlags callBackTypes,
void* info)
{
// LOG_DEBUG(#"noteProcDeath... ");
struct kevent kev;
int fd = CFFileDescriptorGetNativeDescriptor(fdref);
kevent(fd, NULL, 0, &kev, 1, NULL);
// take action on death of process here
unsigned int dead_pid = (unsigned int)kev.ident;
CFFileDescriptorInvalidate(fdref);
CFRelease(fdref); // the CFFileDescriptorRef is no longer of any use in this example
int our_pid = getpid();
// when our parent dies we die as well..
LOG_INFO(#"exit! parent process (pid %u) died. no need for us (pid %i) to stick around", dead_pid, our_pid);
exit(EXIT_SUCCESS);
}
void suicide_if_we_become_a_zombie(int parent_pid) {
// int parent_pid = getppid();
// int our_pid = getpid();
// LOG_ERROR(#"suicide_if_we_become_a_zombie(). parent process (pid %u) that we monitor. our pid %i", parent_pid, our_pid);
int fd = kqueue();
struct kevent kev;
EV_SET(&kev, parent_pid, EVFILT_PROC, EV_ADD|EV_ENABLE, NOTE_EXIT, 0, NULL);
kevent(fd, &kev, 1, NULL, 0, NULL);
CFFileDescriptorRef fdref = CFFileDescriptorCreate(kCFAllocatorDefault, fd, true, noteProcDeath, NULL);
CFFileDescriptorEnableCallBacks(fdref, kCFFileDescriptorReadCallBack);
CFRunLoopSourceRef source = CFFileDescriptorCreateRunLoopSource(kCFAllocatorDefault, fdref, 0);
CFRunLoopAddSource(CFRunLoopGetMain(), source, kCFRunLoopDefaultMode);
CFRelease(source);
}
Inspired by another answer here, I came up with the following all-POSIX solution. The general idea is to create an intermediate process between the parent and the child, that has one purpose: Notice when the parent dies, and explicitly kill the child.
This type of solution is useful when the code in the child can't be modified.
int p[2];
pipe(p);
pid_t child = fork();
if (child == 0) {
close(p[1]); // close write end of pipe
setpgid(0, 0); // prevent ^C in parent from stopping this process
child = fork();
if (child == 0) {
close(p[0]); // close read end of pipe (don't need it here)
exec(...child process here...);
exit(1);
}
read(p[0], 1); // returns when parent exits for any reason
kill(child, 9);
exit(1);
}
There are two small caveats with this method:
If you deliberately kill the intermediate process, then the child won't be killed when the parent dies.
If the child exits before the parent, then the intermediate process will try to kill the original child pid, which could now refer to a different process. (This could be fixed with more code in the intermediate process.)
As an aside, the actual code I'm using is in Python. Here it is for completeness:
def run(*args):
(r, w) = os.pipe()
child = os.fork()
if child == 0:
os.close(w)
os.setpgid(0, 0)
child = os.fork()
if child == 0:
os.close(r)
os.execl(args[0], *args)
os._exit(1)
os.read(r, 1)
os.kill(child, 9)
os._exit(1)
os.close(r)
Does the child process have a pipe to/from the parent process? If so, you'd receive a SIGPIPE if writing, or get EOF when reading - these conditions could be detected.
I don't believe it's possible to guarantee that using only standard POSIX calls. Like real life, once a child is spawned, it has a life of its own.
It is possible for the parent process to catch most possible termination events, and attempt to kill the child process at that point, but there's always some that can't be caught.
For example, no process can catch a SIGKILL. When the kernel handles this signal it will kill the specified process with no notification to that process whatsoever.
To extend the analogy - the only other standard way of doing it is for the child to commit suicide when it finds that it no longer has a parent.
There is a Linux-only way of doing it with prctl(2) - see other answers.
This solution worked for me:
Pass stdin pipe to child - you don't have to write any data into the stream.
Child reads indefinitely from stdin until EOF. An EOF signals that the parent has gone.
This is foolproof and portable way to detect when the parent has gone. Even if parent crashes, OS will close the pipe.
This was for a worker-type process whose existence only made sense when the parent was alive.
Some posters have already mentioned pipes and kqueue. In fact you can also create a pair of connected Unix domain sockets by the socketpair() call. The socket type should be SOCK_STREAM.
Let us suppose you have the two socket file descriptors fd1, fd2. Now fork() to create the child process, which will inherit the fds. In the parent you close fd2 and in the child you close fd1. Now each process can poll() the remaining open fd on its own end for the POLLIN event. As long as each side doesn't explicitly close() its fd during normal lifetime, you can be fairly sure that a POLLHUP flag should indicate the other's termination (no matter clean or not). Upon notified of this event, the child can decide what to do (e.g. to die).
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <poll.h>
#include <stdio.h>
int main(int argc, char ** argv)
{
int sv[2]; /* sv[0] for parent, sv[1] for child */
socketpair(AF_UNIX, SOCK_STREAM, 0, sv);
pid_t pid = fork();
if ( pid > 0 ) { /* parent */
close(sv[1]);
fprintf(stderr, "parent: pid = %d\n", getpid());
sleep(100);
exit(0);
} else { /* child */
close(sv[0]);
fprintf(stderr, "child: pid = %d\n", getpid());
struct pollfd mon;
mon.fd = sv[1];
mon.events = POLLIN;
poll(&mon, 1, -1);
if ( mon.revents & POLLHUP )
fprintf(stderr, "child: parent hung up\n");
exit(0);
}
}
You can try compiling the above proof-of-concept code, and run it in a terminal like ./a.out &. You have roughly 100 seconds to experiment with killing the parent PID by various signals, or it will simply exit. In either case, you should see the message "child: parent hung up".
Compared with the method using SIGPIPE handler, this method doesn't require trying the write() call.
This method is also symmetric, i.e. the processes can use the same channel to monitor each other's existence.
This solution calls only the POSIX functions. I tried this in Linux and FreeBSD. I think it should work on other Unixes but I haven't really tested.
See also:
unix(7) of Linux man pages, unix(4) for FreeBSD, poll(2), socketpair(2), socket(7) on Linux.
Install a trap handler to catch SIGINT, which kills off your child process if it's still alive, though other posters are correct that it won't catch SIGKILL.
Open a .lockfile with exclusive access and have the child poll on it trying to open it - if the open succeeds, the child process should exit
As other people have pointed out, relying on the parent pid to become 1 when the parent exits is non-portable. Instead of waiting for a specific parent process ID, just wait for the ID to change:
pit_t pid = getpid();
switch (fork())
{
case -1:
{
abort(); /* or whatever... */
}
default:
{
/* parent */
exit(0);
}
case 0:
{
/* child */
/* ... */
}
}
/* Wait for parent to exit */
while (getppid() != pid)
;
Add a micro-sleep as desired if you don't want to poll at full speed.
This option seems simpler to me than using a pipe or relying on signals.
I think a quick and dirty way is to create a pipe between child and parent. When parent exits, children will receive a SIGPIPE.
Another way to do this that is Linux specific is to have the parent be created in a new PID namespace. It will then be PID 1 in that namespace, and when it exits it all of it's children will be immediately killed with SIGKILL.
Unfortunately, in order to create a new PID namespace you have to have CAP_SYS_ADMIN. But, this method is very effective and requires no real change to the parent or the children beyond the initial launch of the parent.
See clone(2), pid_namespaces(7), and unshare(2).
Under POSIX, the exit(), _exit() and _Exit() functions are defined to:
If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process.
So, if you arrange for the parent process to be a controlling process for its process group, the child should get a SIGHUP signal when the parent exits. I'm not absolutely sure that happens when the parent crashes, but I think it does. Certainly, for the non-crash cases, it should work fine.
Note that you may have to read quite a lot of fine print - including the Base Definitions (Definitions) section, as well as the System Services information for exit() and setsid() and setpgrp() - to get the complete picture. (So would I!)
If you send a signal to the pid 0, using for instance
kill(0, 2); /* SIGINT */
that signal is sent to the entire process group, thus effectively killing the child.
You can test it easily with something like:
(cat && kill 0) | python
If you then press ^D, you'll see the text "Terminated" as an indication that the Python interpreter have indeed been killed, instead of just exited because of stdin being closed.
In case it is relevant to anyone else, when I spawn JVM instances in forked child processes from C++, the only way I could get the JVM instances to terminate properly after the parent process completed was to do the following. Hopefully someone can provide feedback in the comments if this wasn't the best way to do this.
1) Call prctl(PR_SET_PDEATHSIG, SIGHUP) on the forked child process as suggested before launching the Java app via execv, and
2) Add a shutdown hook to the Java application that polls until its parent PID equals 1, then do a hard Runtime.getRuntime().halt(0). The polling is done by launching a separate shell that runs the ps command (See: How do I find my PID in Java or JRuby on Linux?).
EDIT 130118:
It seems that was not a robust solution. I'm still struggling a bit to understand the nuances of what's going on, but I was still sometimes getting orphan JVM processes when running these applications in screen/SSH sessions.
Instead of polling for the PPID in the Java app, I simply had the shutdown hook perform cleanup followed by a hard halt as above. Then I made sure to invoke waitpid in the C++ parent app on the spawned child process when it was time to terminate everything. This seems to be a more robust solution, as the child process ensures that it terminates, while the parent uses existing references to make sure that its children terminate. Compare this to the previous solution which had the parent process terminate whenever it pleased, and had the children try to figure out if they had been orphaned before terminating.
I found 2 solutions, both not perfect.
1.Kill all children by kill(-pid) when received SIGTERM signal.
Obviously, this solution can not handle "kill -9", but it do work for most case and very simple because it need not to remember all child processes.
var childProc = require('child_process').spawn('tail', ['-f', '/dev/null'], {stdio:'ignore'});
var counter=0;
setInterval(function(){
console.log('c '+(++counter));
},1000);
if (process.platform.slice(0,3) != 'win') {
function killMeAndChildren() {
/*
* On Linux/Unix(Include Mac OS X), kill (-pid) will kill process group, usually
* the process itself and children.
* On Windows, an JOB object has been applied to current process and children,
* so all children will be terminated if current process dies by anyway.
*/
console.log('kill process group');
process.kill(-process.pid, 'SIGKILL');
}
/*
* When you use "kill pid_of_this_process", this callback will be called
*/
process.on('SIGTERM', function(err){
console.log('SIGTERM');
killMeAndChildren();
});
}
By same way, you can install 'exit' handler like above way if you call process.exit somewhere.
Note: Ctrl+C and sudden crash have automatically been processed by OS to kill process group, so no more here.
2.Use chjj/pty.js to spawn your process with controlling terminal attached.
When you kill current process by anyway even kill -9, all child processes will be automatically killed too (by OS?). I guess that because current process hold another side of the terminal, so if current process dies, the child process will get SIGPIPE so dies.
var pty = require('pty.js');
//var term =
pty.spawn('any_child_process', [/*any arguments*/], {
name: 'xterm-color',
cols: 80,
rows: 30,
cwd: process.cwd(),
env: process.env
});
/*optionally you can install data handler
term.on('data', function(data) {
process.stdout.write(data);
});
term.write(.....);
*/
Even though 7 years have passed I've just run into this issue as I'm running SpringBoot application that needs to start webpack-dev-server during development and needs to kill it when the backend process stops.
I try to use Runtime.getRuntime().addShutdownHook but it worked on Windows 10 but not on Windows 7.
I've change it to use a dedicated thread that waits for the process to quit or for InterruptedException which seems to work correctly on both Windows versions.
private void startWebpackDevServer() {
String cmd = isWindows() ? "cmd /c gradlew webPackStart" : "gradlew webPackStart";
logger.info("webpack dev-server " + cmd);
Thread thread = new Thread(() -> {
ProcessBuilder pb = new ProcessBuilder(cmd.split(" "));
pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
pb.redirectError(ProcessBuilder.Redirect.INHERIT);
pb.directory(new File("."));
Process process = null;
try {
// Start the node process
process = pb.start();
// Wait for the node process to quit (blocking)
process.waitFor();
// Ensure the node process is killed
process.destroyForcibly();
System.setProperty(WEBPACK_SERVER_PROPERTY, "true");
} catch (InterruptedException | IOException e) {
// Ensure the node process is killed.
// InterruptedException is thrown when the main process exit.
logger.info("killing webpack dev-server", e);
if (process != null) {
process.destroyForcibly();
}
}
});
thread.start();
}
Historically, from UNIX v7, the process system has detected orphanity of processes by checking a process' parent id. As I say, historically, the init(8) system process is a special process by only one reason: It cannot die. It cannot die because the kernel algorithm to deal with assigning a new parent process id, depends on this fact. when a process executes its exit(2) call (by means of a process system call or by external task as sending it a signal or the like) the kernel reassigns all children of this process the id of the init process as their parent process id. This leads to the most easy test, and most portable way of knowing if a process has got orphan. Just check the result of the getppid(2) system call and if it is the process id of the init(2) process then the process got orphan before the system call.
Two issues emerge from this approach that can lead to issues:
first, we have the possibility of changing the init process to any user process, so How can we assure that the init process will always be parent of all orphan processes? Well, in the exit system call code there's a explicit check to see if the process executing the call is the init process (the process with pid equal to 1) and if that's the case, the kernel panics (It should not be able anymore to maintain the process hierarchy) so it is not permitted for the init process to do an exit(2) call.
second, there's a race condition in the basic test exposed above. Init process' id is assumed historically to be 1, but that's not warranted by the POSIX approach, that states (as exposed in other response) that only a system's process id is reserved for that purpose. Almost no posix implementation does this, and you can assume in original unix derived systems that having 1 as response of getppid(2) system call is enough to assume the process is orphan. Another way to check is to make a getppid(2) just after the fork and compare that value with the result of a new call. This simply doesn't work in all cases, as both call are not atomic together, and the parent process can die after the fork(2) and before the first getppid(2) system call. The processparent id only changes once, when its parent does anexit(2)call, so this should be enough to check if thegetppid(2)result changed between calls to see that parent process has exit. This test is not valid for the actual children of the init process, because they are always children ofinit(8)`, but you can assume safely these processes as having no parent either (except when you substitute in a system the init process)
I've passed parent pid using environment to the child,
then periodically checked if /proc/$ppid exists from the child.
I managed to do a portable, non-polling solution with 3 processes by abusing terminal control and sessions.
The trick is:
process A is started
process A creates a pipe P (and never reads from it)
process A forks into process B
process B creates a new session
process B allocates a virtual terminal for that new session
process B installs SIGCHLD handler to die when the child exits
process B sets a SIGPIPE handler
process B forks into process C
process C does whatever it needs (e.g. exec()s the unmodified binary or runs whatever logic)
process B writes to pipe P (and blocks that way)
process A wait()s on process B and exits when it dies
That way:
if process A dies: process B gets a SIGPIPE and dies
if process B dies: process A's wait() returns and dies, process C gets a SIGHUP (because when the session leader of a session with a terminal attached dies, all processes in the foreground process group get a SIGHUP)
if process C dies: process B gets a SIGCHLD and dies, so process A dies
Shortcomings:
process C can't handle SIGHUP
process C will be run in a different session
process C can't use session/process group API because it'll break the brittle setup
creating a terminal for every such operation is not the best idea ever
If parent dies, PPID of orphans change to 1 - you only need to check your own PPID.
In a way, this is polling, mentioned above.
here is shell piece for that:
check_parent () {
parent=`ps -f|awk '$2=='$PID'{print $3 }'`
echo "parent:$parent"
let parent=$parent+0
if [[ $parent -eq 1 ]]; then
echo "parent is dead, exiting"
exit;
fi
}
PID=$$
cnt=0
while [[ 1 = 1 ]]; do
check_parent
... something
done