Spooling - Learning Module

Loading content...

0/227

Daemon Processes: Background Service Architecture

The Silent Engines of Spooling

Behind every spooling system operates one or more daemon processes—background services that run continuously, waiting for work and processing jobs without direct user interaction. These daemons are the silent engines that transform spooled data into physical output.

The term "daemon" comes from Greek mythology, referring to benevolent spirits that work behind the scenes. In computing, daemons are processes that run in the background, detached from any controlling terminal, providing services to users and system components alike.

What You Will Learn

This page covers daemon architecture, the classic UNIX daemonization process, modern systemd integration, signal handling, privilege management, and how spooler daemons specifically operate. You'll understand how to design, implement, and manage robust background services.

Daemon Characteristics and Requirements

Daemons have specific characteristics that distinguish them from regular processes:

Core Characteristics:

No controlling terminal: Runs detached from any TTY
Long-running: Starts at boot, runs until shutdown
Background execution: No direct user interaction
Parent is init/systemd: PPID is 1
Well-known service port/socket: Accepts requests via IPC

Spooler Daemon Requirements:

Monitor spool directories for new jobs
Accept network connections (IPP, LPD)
Manage job queue ordering and priority
Spawn worker processes for job execution
Handle device communication and errors
Provide status information to clients
Gracefully handle shutdown signals

Common Spooler Daemons
Daemon	Purpose	Protocol	Config File
cupsd	Print spooling (CUPS)	IPP/HTTP	/etc/cups/cupsd.conf
lpd	Legacy print spooling	LPD (RFC 1179)	/etc/printcap
sendmail	Mail transfer agent	SMTP	/etc/mail/sendmail.cf
postfix master	Mail transfer agent	SMTP	/etc/postfix/main.cf
crond	Scheduled job execution	N/A	/etc/crontab
atd	One-time job execution	N/A	/var/spool/at

Classic UNIX Daemonization

Traditional UNIX daemons follow a specific startup ritual to properly detach from the terminal and become background processes. Understanding this process is fundamental to systems programming.

The Daemonization Steps:

Fork and exit parent: Child continues as daemon
Create new session: setsid() becomes session leader
Fork again: Ensure can't acquire controlling terminal
Set working directory: Usually / or specific dir
Reset umask: Set predictable file permissions
Close file descriptors: Disconnect from terminal
Redirect stdio: Send to /dev/null or log file

classic_daemon.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/* Classic UNIX Daemonization Pattern */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <syslog.h>
 
void daemonize(const char *name) {
    pid_t pid;
    
    /* Step 1: Fork and let parent exit */
    pid = fork();
    if (pid < 0) exit(EXIT_FAILURE);
    if (pid > 0) exit(EXIT_SUCCESS);  /* Parent exits */
    
    /* Step 2: Create new session */
    if (setsid() < 0) exit(EXIT_FAILURE);
    
    /* Ignore terminal signals */
    signal(SIGHUP, SIG_IGN);
    
    /* Step 3: Fork again to prevent terminal acquisition */
    pid = fork();
    if (pid < 0) exit(EXIT_FAILURE);
    if (pid > 0) exit(EXIT_SUCCESS);
    
    /* Step 4: Set working directory */
    chdir("/");
    
    /* Step 5: Reset umask */
    umask(0);
    
    /* Step 6: Close standard file descriptors */
    close(STDIN_FILENO);
    close(STDOUT_FILENO);
    close(STDERR_FILENO);
    
    /* Step 7: Redirect to /dev/null */
    open("/dev/null", O_RDONLY);   /* stdin  = fd 0 */
    open("/dev/null", O_WRONLY);   /* stdout = fd 1 */
    open("/dev/null", O_WRONLY);   /* stderr = fd 2 */
    
    /* Open syslog for logging */
    openlog(name, LOG_PID, LOG_DAEMON);
    syslog(LOG_INFO, "Daemon started successfully");
}
 
/* Main daemon loop */
int main(int argc, char *argv[]) {
    daemonize("myspooler");
    
    /* Create PID file */
    write_pid_file("/var/run/myspooler.pid");
    
    /* Main service loop */
    while (1) {
        /* Check for new jobs */
        process_spool_queue();
        
        /* Sleep or wait for signals */
        sleep(1);
    }
    
    return 0;
}

Why Fork Twice?

The double-fork ensures the daemon cannot accidentally acquire a controlling terminal. After setsid(), the process is a session leader and could get a terminal if it opens one. The second fork creates a non-session-leader that can never acquire a controlling terminal.

Modern Systemd Integration

Modern Linux systems use systemd for service management. Daemons designed for systemd are simpler—they don't need to daemonize themselves because systemd handles process supervision.

Systemd Advantages:

Automatic restart on crash
Resource limits (CPU, memory, file descriptors)
Dependency management
Socket activation (start on first connection)
Centralized logging (journald)
Consistent status reporting

cups.service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# /lib/systemd/system/cups.service
[Unit]
Description=CUPS Scheduler
Documentation=man:cupsd(8)
After=network.target nss-user-lookup.target
Wants=cups.socket cups.path
 
[Service]
Type=notify
ExecStart=/usr/sbin/cupsd -l
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
 
# Security hardening
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
 
# File descriptor limit
LimitNOFILE=8192
 
[Install]
WantedBy=multi-user.target

manage_daemon.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/bin/bash
# Managing daemons with systemctl
 
# Start/stop/restart
systemctl start cups
systemctl stop cups
systemctl restart cups
systemctl reload cups   # HUP signal for config reload
 
# Enable/disable at boot
systemctl enable cups
systemctl disable cups
 
# Status and logs
systemctl status cups
journalctl -u cups -f   # Follow logs
 
# Check if running
systemctl is-active cups
 
# List all spool-related services
systemctl list-units --type=service | grep -E 'cups|postfix|cron'

Systemd Service Types
Type	Description	Use Case
simple	Main process is the service	Most daemons
forking	Service forks and parent exits	Legacy daemons
notify	Service sends ready notification	Modern daemons
oneshot	Single execution, then done	Startup scripts
dbus	Ready when on D-Bus	Desktop services

Signal Handling and Lifecycle

Daemons must handle UNIX signals properly for clean operation, configuration reload, and graceful shutdown.

Essential Signals:

Signal Handling in Daemons
Signal	Default Action	Daemon Should
SIGHUP	Terminate	Reload configuration
SIGTERM	Terminate	Graceful shutdown
SIGINT	Terminate	Graceful shutdown
SIGCHLD	Ignore	Reap child processes
SIGUSR1/2	Terminate	Custom actions (log rotate, etc.)
SIGPIPE	Terminate	Ignore (handle in code)

signal_handling.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/* Proper Signal Handling for Spooler Daemon */
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <syslog.h>
 
static volatile sig_atomic_t running = 1;
static volatile sig_atomic_t reload_config = 0;
 
void handle_signal(int sig) {
    switch (sig) {
        case SIGTERM:
        case SIGINT:
            syslog(LOG_INFO, "Shutdown requested");
            running = 0;
            break;
        case SIGHUP:
            syslog(LOG_INFO, "Config reload requested");
            reload_config = 1;
            break;
        case SIGCHLD:
            /* Reap zombie children */
            while (waitpid(-1, NULL, WNOHANG) > 0);
            break;
    }
}
 
void setup_signals(void) {
    struct sigaction sa;
    
    sa.sa_handler = handle_signal;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;  /* Restart interrupted syscalls */
    
    sigaction(SIGTERM, &sa, NULL);
    sigaction(SIGINT, &sa, NULL);
    sigaction(SIGHUP, &sa, NULL);
    sigaction(SIGCHLD, &sa, NULL);
    
    /* Ignore SIGPIPE - handle write errors in code */
    signal(SIGPIPE, SIG_IGN);
}
 
void daemon_main_loop(void) {
    setup_signals();
    
    while (running) {
        if (reload_config) {
            syslog(LOG_INFO, "Reloading configuration");
            load_config();
            reload_config = 0;
        }
        
        /* Process jobs, accept connections, etc. */
        do_work();
    }
    
    /* Graceful shutdown */
    syslog(LOG_INFO, "Finishing pending jobs...");
    finish_pending_jobs();
    cleanup_resources();
    syslog(LOG_INFO, "Daemon exiting");
}

Privilege Management and Security

Daemons often need elevated privileges at startup but should drop to minimal privileges for ongoing operation.

Privilege Dropping Pattern:

Start as root (to bind privileged ports, access devices)
Open required resources (ports, devices, files)
Drop to unprivileged user/group
Optionally chroot or use namespaces for further isolation

CUPS Privilege Model:

Starts as root
Binds port 631
Drops to user lp for job processing
Filter processes run as job owner (if possible)
Backend may elevate for device access

drop_privileges.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/* Drop Privileges After Initialization */
#include <pwd.h>
#include <grp.h>
#include <unistd.h>
#include <sys/types.h>
 
int drop_privileges(const char *username) {
    struct passwd *pw = getpwnam(username);
    if (!pw) return -1;
    
    /* Set supplementary groups */
    if (initgroups(username, pw->pw_gid) != 0) {
        return -1;
    }
    
    /* Set group ID first (can't after setuid) */
    if (setgid(pw->pw_gid) != 0) {
        return -1;
    }
    
    /* Set user ID - no going back after this */
    if (setuid(pw->pw_uid) != 0) {
        return -1;
    }
    
    /* Verify we can't regain root */
    if (setuid(0) == 0) {
        /* Security failure - still have root */
        return -1;
    }
    
    return 0;
}
 
int main(void) {
    /* Phase 1: Root-privileged initialization */
    int server_fd = bind_privileged_port(631);
    if (server_fd < 0) exit(1);
    
    open_device("/dev/lp0");  /* Needs device access */
    
    /* Phase 2: Drop privileges */
    if (drop_privileges("lp") != 0) {
        syslog(LOG_ERR, "Failed to drop privileges");
        exit(1);
    }
    
    /* Phase 3: Run as unprivileged user */
    syslog(LOG_INFO, "Running as uid %d", getuid());
    daemon_main_loop();
    
    return 0;
}

Never Skip Privilege Dropping

Running services as root longer than necessary is a major security risk. A vulnerability in a root daemon gives attackers complete system control. Always drop to the minimum required privileges as early as possible.

Daemon Process Models

Daemons use different process models to handle concurrent work:

1. Single-Process (Event Loop)

One process handles all work using select/poll/epoll
Efficient for I/O-bound workloads
Example: nginx, Redis

2. Pre-fork (Worker Pool)

Master process forks N workers at startup
Workers handle requests independently
Example: Apache prefork, PostgreSQL

3. Fork-on-Demand

New process forked for each request
Simple isolation but high overhead
Example: traditional CGI, inetd

4. Thread Pool

Pool of threads within one process
Lower overhead than forking
Example: Apache worker, Java servers

CUPS Model: CUPS uses a hybrid: single scheduler process with forked filters and backends per job. This isolates job processing while maintaining efficient queue management.

Process Model Comparison
Model	Isolation	Overhead	Concurrency	Best For
Event Loop	None	Lowest	High	I/O-bound, many connections
Pre-fork	Per-worker	Medium	Limited by pool	CPU-bound, memory isolation
Fork-on-Demand	Per-request	Highest	Unlimited	Infrequent, untrusted code
Thread Pool	Partial	Low	High	Shared state, lower isolation OK

Summary

Key Takeaways

•Daemons run detached — No controlling terminal, long-running background services
•Classic daemonization — Double-fork, setsid, redirect stdio pattern
•Systemd integration — Modern approach with supervision, socket activation, journald
•Signal handling — SIGHUP for reload, SIGTERM for graceful shutdown
•Privilege dropping — Start as root, drop to unprivileged user ASAP
•Process models — Event loop, pre-fork, fork-on-demand, thread pool each have tradeoffs

The final page covers job scheduling—how spooling systems decide which jobs to process, priority algorithms, fairness policies, and scheduling optimization.