Background, zombie, daemon and without ctty – are these concepts connected

background-processcontrolling-terminaldaemonjob-controlzombie-process

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 parent
  • daemon — without ctty – all daemons run without ctty, but not all processes withoutctty are daemons
  • background — daemon – a background process can be retrieved to run interactively again, daemon is not
  • zombie — without ctty – zombie is indifferent if there is ctty attached to it or not
  • background — without ctty – processes sent to background while they have ctty, and become daemons or die if the ctty is taken from them

Best Answer

In brief, plus links.

zombie

a 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:

controlling terminal, session, foreground, background

These 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:

daemon

A 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:

Related Question