a daemon
/ DEE-mun or DAY-mun /
Some programs are meant to be used and then quit - you run ls, it prints, it ends. But others are meant to run quietly forever in the background, waiting to do their job whenever they are needed: a web server waiting for requests, a print spooler waiting for documents, a clock-sync service ticking along. A program like that, running as a long-lived background process with no controlling terminal, is called a daemon. The name (an old spelling of a helpful spirit, not a demon) captures it: an unseen helper working in the background.
What makes a process a daemon, concretely, is that it has deliberately detached itself from any terminal and any user session, so it keeps running independent of who is logged in. The traditional recipe walks through several steps: fork() and let the parent exit (so the child is no longer a process-group leader and becomes an orphan adopted by init); call setsid() to start a new session and shed the controlling terminal; often fork() a second time so the daemon can never reacquire a terminal; change the working directory to a safe place like /; reset the file mode mask; and close or redirect the standard input, output, and error streams (usually to /dev/null or a log file) since there is no terminal to read from or write to. The result is a process whose PPID is 1, that has no terminal, and that survives your logout. On modern systems you rarely write all this by hand - an init system like systemd launches and supervises services for you, handling the detachment, logging, and restart-on-crash - but the underlying idea is the same.
Why it matters: daemons are how a computer provides services - nearly everything a server 'does' is a daemon patiently waiting and responding. Understanding daemonization ties this whole field together: it uses fork (to create the process), the orphan-and-reparent mechanism (so init adopts it), sessions and controlling terminals (to detach), and credentials (daemons usually drop to an unprivileged user for safety). A common beginner mistake is to start a server straight from a shell and be surprised when closing the terminal kills it - that is precisely the controlling-terminal connection a real daemon takes care to break.
sshd, cron, and a web server like nginx are daemons: ps shows them with PPID 1 and a '?' in the TTY column, meaning no controlling terminal. They were started at boot, detached from any session, and keep running while users log in and out around them.
A daemon: PPID 1, no controlling terminal (TTY '?'), running quietly in the background.
Starting a server from a shell does not make it a daemon - it is still tied to that terminal and dies when the terminal closes (a hang-up signal). True daemonization deliberately detaches via setsid and reparenting; modern systems delegate this to systemd or similar.