“Interactive, batch, and daemon” is a useful operational classification, but these are not three mutually exclusive kernel process types. Linux sees processes and threads with states, parents, credentials, scheduling properties, and resources. Humans add labels based on how the processes are used.
Interactive processes
An interactive process is attached to a terminal or user session and exchanges input or output with a user.
1 | vim notes.md |
A process can run in the foreground or background of a shell job. Backgrounding it does not automatically make it a daemon.
Batch processes
Batch work runs without continuous user interaction, often from a scheduler or queue:
1 | 0 2 * * * /usr/local/bin/backup |
Cron jobs, CI jobs, and background workers are common examples. A batch process can still write logs and fail spectacularly at 2 a.m., when it knows nobody is watching.
Daemons and services
A daemon is a long-running background process that provides a service, such as sshd, nginx, or a database server. Modern Linux systems commonly let systemd manage daemon lifecycle, logs, dependencies, and restart policies.
A daemon’s PID is not always init. PID 1 belongs to the init system—commonly systemd—which starts and supervises other processes. Each daemon has its own PID.
Traditional daemonization involved forking, creating a new session, changing directories, and closing inherited file descriptors. Under systemd, services often stay in the foreground and let the supervisor manage them. Double-forking everything because a 1998 tutorial said so is mostly historical cosplay.
Process states
Tools such as ps expose kernel states including running, sleeping, stopped, and zombie:
1 | ps -eo pid,ppid,state,tty,cmd |
These states are different from operational labels. A daemon can be sleeping, a batch job can be running, and an interactive process can be stopped.