A daemon is a program that runs quietly in the background, doing its work without an interactive user attached to it. The daemon(7) manual page gives the definition: “A daemon is a service process that runs in the background and supervises the system or provides functionality to other processes.” Web servers, mail servers, the cron scheduler, system loggers, and the print spooler are all daemons. They start at boot, wait for work, and keep running until the machine shuts down.
The naming convention is part of the culture. Daemon programs conventionally end in the letter d: crond, sshd, httpd, syslogd, systemd. The d is short for daemon and instantly signals “this is a long-running background service.” The term itself was borrowed at MIT from Maxwell’s demon, the imaginary agent that sorts molecules in the background; the spelling daemon, and the deliberate distance from “demon,” became fixed in Unix usage.
Turning an ordinary program into a daemon traditionally meant a specific dance to cut its ties to the terminal and session that launched it. The daemon(7) page lays out the classic SysV-style sequence, whose heart is the double fork. The process forks once and the parent exits, so the child is no longer a process-group leader; the child calls setsid() to start a new session with no controlling terminal; then it forks a second time, so the final process can never reacquire a terminal. Along the way it resets file-mode creation masks, closes inherited file descriptors, and redirects standard input, output, and error away from the console. The result is a process that survives logouts, has no terminal to be killed by, and is reparented under PID 1.
Modern init systems have largely retired that ritual. The same manual page describes “new-style” daemons designed to run under a service manager such as systemd, and states that for them “none of the [SysV] initialization steps are necessary or recommended.” Instead the init system handles the environment, file descriptors, and signal setup, and the daemon simply runs in the foreground, telling the manager when it is ready (for example via sd_notify()) and responding to SIGTERM for graceful shutdown and SIGHUP to reload its configuration. The manager, not the daemon, owns the backgrounding.
The concept matters because so much of what a computer does is invisible service work. The interactive programs a person uses, a browser, an editor, a shell, sit on top of a quiet population of daemons handling network connections, logging, time synchronization, scheduled jobs, and device events. The daemon is the unit in which that always-on background work is packaged.
Whether it daemonizes itself the old way or is supervised by systemd the new way, the defining trait is the same: a daemon outlives any one user session, provides an ongoing service, and is meant to be running whenever the system is up.