" Thus, the common method for launching a daemon involves forking once or twice, and making the parent processes die while the child process begins performing its normal function."
I was going through OS concepts and I didn't understand the above said lines.
Why the parent process will be made to exit( or parent dying ),in the process of creating a Daemon?
Can someone pls explain me.
Traditionally, a daemon process is defined as a process whose parent is the system's init process and which runs in the background. For instance, if you were to execute some program in your terminal, your shell would create a process (either in the foreground or background) and the program would run with your shell as its parent. This is an example of a non-daemon process because its parent is your shell process.
So how do you produce a process whose parent is the init process? Well, a process whose parent process dies before it (the child) has exited becomes an orphan process. An orphan process will in turn be re-parented to the init process. Voila, the process now meets the definition of a daemon.
Tying this back to your quote, if you were to fork once and then kill the parent, you achieve the desired effect. Likewise, if you fork once and then have that child fork another process, followed by killing the first child, you also achieve the desired effect while keeping the (now grandparent) process alive.
This is not a requirement, as any background process could be a daemon. Technically a daemon process in one that runs to operate some general non interactive task. In Unix environment, a daemon is generally set as a process that have some characteristics: no controlling terminal, no umask, particular working directory, etc. Forking twice is a common way to obtain the grandchild to be inherited by init process and have the former properties, in some way to get a process fully detached of any user control (except root of course).
This applies only if a standard user want to create a daemon. Some other standard daemons are created almost normally (see init, launchd, etc)
If the parent exits while the daemon continues running, the daemon is orphaned, and the init process typically adopts it (i.e. becomes the parent).
There are some exceptions, but it is normally expected that a daemon process will be descended from the init process (e.g. the init process will launch daemons during system startup). So, if another process launches a daemon and terminates, it achieves the desired effect.
Note that some other actions are also needed, such as disassociating the daemon from any tty window.
Other answers already explained what happens when parent dies i.e. child is adopted by init process.
But why above is required to make a process daemon? A daemon by definition is non-interacting program i.e. it should not be associated with a terminal. That ensures that daemon continues to work in background even when user sends signals by Control-C, hangup etc. Now, how to prevent a process from ever attaching to a terminal? Make init it's parent by killing original parent.
init is a special process because:
It's not attached to any terminal.
It's first process (pid 1) after booting OS, and that makes it leader of it's session. Note that every UNIX process belongs a process group and that in turn belongs to a session. First process in the session becomes session leader.
In UNIX, only session leader can attach to (or control) terminal. As soon as you make init parent of your process, it joins init's session. Since init is the session leader, your process can never be the leader and hence can never attach to a terminal. That's what we wanted, right?
There are other ways to detach terminal e.g. calling setsid but that's not part of this discussion.
Related
Well, I'm learning about processes using the C language, and I have seen that when you call the exit function a process is terminated and without waiting for it, it will become a zombie process. My question is, if the first process created when executing the program is a process itself, is there a 0S routine that wait for it after an exit() call, avoiding that it becomes a zombie process? I'm curious about it.
For Unix systems at least (and I expect Windows is similar), when the system boots, it creates one special first process. Every process after that is created by some existing process.
When you log into a windowed desktop interface, there is some desktop manager process (that has been created by the first process or one of its descendants) managing windows. When you start a program by clicking on it, that desktop manager or one of its children (maybe some file manager software) creates a process to run the program. When you start a program by executing a command in a terminal window, there is a command line shell process that is interpreting the things you type, and it creates a process to run the program.
So, in all cases, your user program has a parent process, either a command-line shell or some desktop software.
If a child process creates another child (even as the first instruction) then the parent also has to wait for it or it becomes a zombie.
Basically processes always become zombie until they are removed from the process table, the OS (via the process init) will handle and wait() for orphans (zombies without parents), it does that periodically so normally you won't have orphans running for very long.
On Linux, the top most (parent) process is init. This is the only process, which has no parent. Any other process (without any exception) do have a parent and hence is a child of another process.
See:
init
Section NOTES on wait
A child that terminates, but has not been waited for becomes a
"zombie". The kernel maintains a minimal set of information
about the zombie process (PID, termination status, resource usage
information) in order to allow the parent to later perform a wait
to obtain information about the child. As long as a zombie is
not removed from the system via a wait, it will consume a slot in
the kernel process table, and if this table fills, it will not be
possible to create further processes. If a parent process
terminates, then its "zombie" children (if any) are adopted by
init(1), ... init(1) automatically performs a wait to remove the
zombies.
I'm trying to write a mock-shell in c on linux, and got stuck on this problem:
I need to run some processes in the background, and some processes in the foreground.
To prevent the foreground processes from becoming zombies, I can use wait(), but how do I prevent the background processes from becoming zombies?
You cannot prevent any process from becoming a zombie, but you can limit the time that it remains one. A process is a zombie from the time it terminates to the time its parent collects it via a call to wait() or waitpid() or another function serving that purpose. That time can be made very short indeed, for instance if the parent process is already waiting when the child terminates, but termination and subsequent collection are not synchronous.
The distinction between background and foreground processes is primarily about control of a terminal; it has little to do with a parent shell managing child processes. You collect child processes belonging to background jobs via wait(), etc., exactly the same way you collect child processes belonging to foreground jobs. You can can collect already-terminated children without waiting for unterminated ones by using waitpid() with the W_NOHANG flag, as #Someprogrammerdude already described. It remains to insert such waits at an appropriate time, and it seems common for interactive shells to schedule that around reading commands from the user.
You can poll for the, using waitpid with the W_NOHANG flag. Or you could add a SIGCHLD handler which will be invoked each time a child-process ends (or have other status changes).
In the first scenario, a process calls setsid() to start a new session and become its leader, and calls open() to connect to a controlling terminal. Then the session leader goes on to fork() child processes, and the children will inherit the file descriptor to the controlling terminal.
In the second scenario, if a session already has multiple processes and but has no controlling terminal, and then the leader creates a connection to a controlling terminal, what about the other processes in the session:
how would the other processes in the session learn that the session has a controlling terminal and
how could they open the controlling terminal as a file descriptor?
Thanks.
Originated from https://unix.stackexchange.com/questions/446207/for-a-process-what-are-the-differences-between-a-controlling-terminal-and-non-c
The controlling terminal is described in a lot of documentation as a property of an entire session, but it's really a property of each individual process, which is inherited from parent to child in fork. A process has to be a session leader to attach itself to a controlling tty, but any process can detach from its controlling tty, if it has one, with the TIOCNOTTY ioctl. So the system is set up to handle processes that are in a session but not attached to a controlling tty.
In your "second scenario", processes that the session leader forked before attaching to a controlling tty do not get attached to that tty along with it. This means that they are not entirely part of the session, in the same way that processes that have detached from the controlling tty are not entirely part of the session: they can't be put into the foreground with tcsetpgrp, they cannot open /dev/tty, they don't receive SIGHUP if the controlling tty hangs up, etc. Processes that the session leader forks after it attaches a controlling tty, on the other hand, will inherit it as usual.
(As a general rule, in Unix, operations that manipulate the calling process's state never have any effect on any other process, even if it seems like they ought to; also as a general rule, when we say such and such is inherited over a fork, we mean that piece of state is copied into the child, not shared between parent and child. An important exception is "open file description"s, which are shared. If you have a regular file open in a process that forks, and the child calls lseek on its inherited file descriptor, the parent will see the seek pointer move.)
I was trying to write a basic multiprocessing tcp-server, which forks a process for every new accept().
I don't need the parent process to wait on the child processes. I have come across two solutions- forking twice and daemonising.
What's the difference between the two?
Which is more suitable in this scenario?
What are the factors that are to be kept in mind for choosing one amongst these?
There is a subtle difference.
Forking twice: Intermediate child process can't become a zombie provided it has exited and has been waited for by Parent. Grandchild can't become a zombie either as it's parent (intermediate child process) has exited, so grandchild is an orphan. The orphan(grandchild) gets inherited by init and if it exits now, it is the responsibility of the system to clean it up. In this way, the parent process is releived of the responsibility of waiting to collect the exit status signal from child and also the parent can be busy doing some other work. This also enables the child to run for long time so that a shorttime parent need not wait for that amount of time.
Daemon: This is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons. Has no controlling terminal.
The decision of approach depends on the requirement/scenario in hand.
You do need the parent process to (eventually) wait() for each of its child processes, else the children will hang around until the parent exits. This is a form of resource leak.
Forking twice, with the intermediate process exiting immediately after forking, allows the original process to collect the child immediately (via wait()), and makes the grandchild process an orphan, which the system has responsibility for cleaning up. This is one way to avoid accumulating zombie processes. The grandchild remains in the same process group (and thus the same session) as the original process.
Daemonizing serves a somewhat different purpose. It puts the resulting (child) process in a new session (and new process group) with no controlling terminal. The same effect can be achieved by forking once, with the parent immediately calling _exit() and the child calling setsid().
A system service daemonizes to escape the session in which it was launched, so as not to be shut down when that session ends. This has little to do with multiprocessing, but a lot to do with process management. A process double-forks to avoid process management duties for the (grand)child processes; this has both multiprocessing and process management aspects.
Note, too, that double-forking doesn't just pass off process-management responsibilty, it also gives up process-management ability. Whether that's a good trade-off is situation-dependent.
Current scenario, I launch a process that forks, and after a while it aborts().
The thing is that both the fork and the original process print to the shell, but after the original one dies, the shell "returns" to the prompt.
I'd like to avoid the shell returning to the prompt and keep as if the process didn't die, having the child handle the situation there.
I'm trying to figure out how to do it but nothing yet, my first guess goes somewhere around tty handling, but not sure how that works.
I forgot to mention, the shell takeover for the child could be done on fork-time, if that makes it easier, via fd replication or some redirection.
I think you'll probably have to go with a third process that handles user interaction, communicating with the "parent" and "child" through pipes.
You can even make it a fairly lightweight wrapper, just passing data back and forth to the parent and terminal until the parent dies, and then switching to passing to/from the child.
To add a little further, as well, I think the fundamental problem you're going to run into is that the execution of a command by the shell just doesn't work that way. The shell is doing the equivalent of calling system() -- it's going to wait for the process it just spawned to die, and once it does, it's going to present the user with a prompt again. It's not really a tty issue, it's how the shell works.
bash (and I believe other shells) have the wait command:
wait: wait [n]
Wait for the specified process and report its termination status. If
N is not given, all currently active child processes are waited for,
and the return code is zero. N may be a process ID or a job
specification; if a job spec is given, all processes in the job's
pipeline are waited for.
Have you considered inverting the parent child relationship?
If the order in which the new processes will die is predictable, run the code that will abort in the "child" and the code that will continue in the parent.