How these process concepts are related together - background, zombie, daemon and without controlling terminal?I feel that they are somehow close, especially through the concept of controlling terminal, but there is still not much info for me to tell a story, like if you need to explain something to a child reading an article about Linux without lying too much.UPDATE #1: For example (I don't know if that's true)background -- zombie - foreground process can not become zombie, because zombie is a background process that was left without a parentdaemon -- without ctty - all daemons run without ctty, but not all processes withoutctty are daemonsbackground -- daemon - a background process can be retrieved to run interactively again, daemon is notzombie -- without ctty - zombie is indifferent if there is ctty attached to it or notbackground -- without ctty - processes sent to background while they have ctty, and become daemons or die if the ctty is taken from them
Background, zombie, daemon and without ctty - are these concepts connected?
background process;daemon;job control;zombie process;controlling terminal
In brief, plus links.zombiea process that has exited/terminated, but whose parent has not yet acknowledged the termination (using the wait() system calls). Dead processes are kept in the process table so that their parent can be informed that their child of the child process exiting, and of their exit status. Usually a program forking children will also read their exit status as they exit, so you'll see zombies only if the parent is stopped or buggy.See: Can a zombie have orphans? Will the orphan children be disturbed by reaping the zombie?How does Linux handle zombie processes?Linux man page waitpid(2)controlling terminal, session, foreground, backgroundThese are related to job control in the context of a shell running on a terminal. A user logs in, a session is started, tied to a terminal (the controlling terminal) and a shell is started. The shell then runs processes and sends them on the foreground and background as the user wishes (using & when starting the process, stopping it with ^Z, using fg and bg).Processes in the background are stopped if reading or writing from the terminal; processes in the foreground receive the interrupt signal if ^C is hit on the terminal. (It's the kernel's terminal driver that handles those signals, the shell controls which process (group) is sent to the foreground or background.See: Difference between nohup, disown and &Bash reference manual: Job Control BasicsdaemonA process running as a daemon is usually something that shouldn't be tied to any particular terminal (or a login session, or a shell). It shouldn't have a controlling terminal, so that it won't receive signals if the terminal closes, and one usually doesn't want it to do I/O on a terminal either. Starting a daemon from the command line requires breaking all ties to the terminal, i.e. starting a new session (in the job control sense, above) to get rid of the controlling terminal, and closing the file handles to the terminal. Of course something started from init, systemd or similar outside a login session wouldn't have these ties to begin with.Since a daemon doesn't have a controlling terminal, it's not subject to job control, and being in the foreground or background in the job control sense doesn't apply. Also, daemons usually re-parent to init which cleans them as they exit, so you don't usually see them as zombies.See: What's the difference between running a program as a daemon and forking it into background with '&'?Linux man page daemon(7).