← Process Control (APUE)

Select a question from the sidebar

18 questions in this topic

Question 1 / 18

How does fork() work, and what are its return values?

fork() creates a new process by duplicating the calling process. The new process (child) is an almost exact copy of the parent.

Prototype:

#include <unistd.h>
pid_t fork(void);

Return values:

In the parent: returns the child's PID (positive integer)
In the child: returns 0
On failure: returns -1 (no child created), sets errno

What the child inherits (copies of):

Data segment, heap, stack (copy-on-write)
Open file descriptors (shared open file table entries)
Signal dispositions, environment, CWD, umask
Real/effective UID and GID

What differs:

PID (child gets a new PID)
PPID (child's parent PID = original process PID)
Pending signals (cleared in child)
File locks (NOT inherited)
Return value of fork()

After fork(), both parent and child continue executing from the instruction after the fork() call. The execution order is indeterminate.

Pseudo Code

1. pid = fork()
2. If pid == -1: error, no child created
3. If pid == 0: this is the child process
4. If pid > 0: this is the parent, pid = child's PID
5. Both processes continue from the line after fork()
6. Child is a copy-on-write duplicate of parent
7. Open file descriptors are shared (same open file table entries)

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    int x = 42;
    printf("Before fork: pid=%d, x=%d\n", getpid(), x);

    pid_t pid = fork();
    if (pid == -1) {
        perror("fork");
        return 1;
    }

    if (pid == 0) {
        /* Child process */
        x = 100;  /* modifies child's copy only (COW) */
        printf("Child:  pid=%d, ppid=%d, x=%d\n", getpid(), getppid(), x);
        _exit(0);
    } else {
        /* Parent process */
        printf("Parent: pid=%d, child=%d, x=%d\n", getpid(), pid, x);
        wait(NULL);  /* wait for child */
        printf("Parent: x still %d (unaffected by child)\n", x);
    }

    return 0;
}

Before fork: pid=12345, x=42
Parent: pid=12345, child=12346, x=42
Child:  pid=12346, ppid=12345, x=100
Parent: x still 42 (unaffected by child)

Key Points

•fork() returns child PID to parent, 0 to child, -1 on error
•Child is a copy-on-write duplicate of the parent
•Open file descriptors are shared (same open file table entry)
•Execution order after fork is indeterminate
•Child gets new PID but inherits parent's data, heap, stack

Gotchas

•stdio buffers are duplicated -- flush before fork to avoid double output
•Shared file descriptors mean shared file offsets -- writes can interleave
•fork() can fail with EAGAIN if process limit (RLIMIT_NPROC) is reached
•The child should call _exit(), not exit(), to avoid flushing parent's stdio buffers

fork() creates a child process. Returns child PID to parent, 0 to child, -1 on error. Child is a copy-on-write copy of parent with shared file descriptors.

•Returns child PID to parent, 0 to child
•Child is copy-on-write duplicate

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();
    if (pid == 0) {
        printf("Child: pid=%d\n", getpid());
        _exit(0);
    } else if (pid > 0) {
        printf("Parent: child=%d\n", pid);
        wait(NULL);
    }
    return 0;
}

Parent: child=12346
Child: pid=12346

Flush stdio buffers before fork to avoid double output

Question 2 / 18

What is copy-on-write (COW) semantics in the context of fork()?

Copy-on-write (COW) is an optimization used by modern UNIX kernels to make fork() efficient.

Without COW (old behavior): fork() would physically copy the entire address space of the parent (data, heap, stack) to the child. For a process using 1GB of memory, fork() would allocate and copy 1GB -- very slow.

With COW (modern behavior):

After fork(), parent and child share the same physical memory pages
Pages are marked as read-only in both processes' page tables
When either process writes to a shared page, a page fault occurs
The kernel then copies just that one page and remaps it as read-write
Only modified pages are ever copied

Benefits:

fork() is nearly instantaneous regardless of process memory size
If the child immediately calls exec(), most pages are never copied
Memory-efficient: unmodified pages remain shared

The fork+exec pattern (most common use of fork) benefits enormously:

fork() shares all pages with COW
exec() replaces the entire address space
Only the few pages touched between fork and exec are ever copied

Pseudo Code

Before fork:
  Parent pages: [P1] [P2] [P3] (read-write)

After fork (COW):
  Parent page table: [P1*] [P2*] [P3*] (read-only)
  Child page table:  [P1*] [P2*] [P3*] (read-only, same physical pages)

Child writes to P2:
  1. Page fault on P2
  2. Kernel copies P2 -> P2'
  3. Child page table: [P1*] [P2'] [P3*] (P2' is read-write)
  4. Parent page table: [P1*] [P2*] [P3*] (P2* back to read-write, refcount=1)
  
Only 1 page copied instead of 3!

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>

int main(void) {
    /* Allocate a large buffer */
    size_t size = 100 * 1024 * 1024;  /* 100 MB */
    char *buf = malloc(size);
    if (!buf) { perror("malloc"); return 1; }
    memset(buf, 'A', size);  /* touch all pages */

    printf("Parent: allocated %zu MB, buf[0]='%c'\n", size / (1024*1024), buf[0]);

    pid_t pid = fork();
    /* fork() is fast despite 100MB -- COW shares pages */

    if (pid == 0) {
        /* Child: reading shared pages -- no copy needed */
        printf("Child: buf[0]='%c' (shared page, no copy)\n", buf[0]);

        /* Writing triggers COW for just this page (4KB) */
        buf[0] = 'B';
        printf("Child: buf[0]='%c' (COW: only this page copied)\n", buf[0]);

        free(buf);
        _exit(0);
    } else {
        wait(NULL);
        printf("Parent: buf[0]='%c' (unchanged)\n", buf[0]);  /* still 'A' */
        free(buf);
    }

    return 0;
}

Parent: allocated 100 MB, buf[0]='A'
Child: buf[0]='A' (shared page, no copy)
Child: buf[0]='B' (COW: only this page copied)
Parent: buf[0]='A' (unchanged)

Key Points

•COW makes fork() O(1) regardless of process memory size
•Parent and child share physical pages until one writes
•Only modified pages are physically copied (one page at a time)
•The fork+exec pattern rarely copies any pages
•Page tables are copied (small) but not the actual data pages

Gotchas

•A process that writes to all its memory after fork will eventually copy everything anyway
•COW page faults have overhead -- massive writes after fork can be slower than expected
•overcommit: fork may succeed even without enough memory for a full copy, but OOM killer may strike later
•malloc does not actually allocate pages until they are written (demand paging + COW compound)

COW means fork() shares physical memory pages between parent and child. Pages are marked read-only; when either writes, only that page is copied. Makes fork() fast even for large processes.

•fork shares pages; copy on first write
•fork+exec rarely copies any pages

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    int x = 42;
    pid_t pid = fork();  /* fast: pages shared with COW */
    if (pid == 0) {
        x = 99;  /* triggers COW: only this page copied */
        printf("Child: x=%d\n", x);  /* 99 */
        _exit(0);
    }
    wait(NULL);
    printf("Parent: x=%d\n", x);  /* still 42 */
    return 0;
}

Child: x=99
Parent: x=42

Overcommit may let fork succeed without enough memory for full copy

Question 3 / 18

What is the exec family of functions, and how do the variants differ?

The exec family replaces the current process image with a new program. After exec, the calling process's code, data, heap, and stack are replaced.

Six variants (mnemonic: l=list, v=vector, e=environment, p=PATH):

Function	Args	PATH search	Environment
`execl`	list	no	inherited
`execlp`	list	yes	inherited
`execle`	list	no	explicit
`execv`	array	no	inherited
`execvp`	array	yes	inherited
`execve`	array	no	explicit

l (list): arguments passed as individual parameters, terminated by (char *)NULL
v (vector): arguments passed as a char *argv[] array
p (path): searches PATH environment variable for the executable
e (environment): takes an explicit char *envp[] array

execve() is the actual system call; all others are library wrappers.

What is preserved across exec:

PID, PPID, real UID/GID
File descriptors (unless FD_CLOEXEC is set)
Signal dispositions set to SIG_DFL or SIG_IGN (custom handlers reset to SIG_DFL)

What is NOT preserved:

Memory mappings, code, data, heap, stack
Pending signals
Memory locks

Pseudo Code

exec variants naming:
  l = list args:    execl("/bin/ls", "ls", "-l", NULL)
  v = vector args:  execv("/bin/ls", argv)
  p = PATH search:  execlp("ls", "ls", "-l", NULL)
  e = environment:  execle("/bin/env", "env", NULL, envp)

Only execve() is a syscall; others are wrappers.

exec does NOT return on success (the process image is replaced).
If exec returns, it failed (returns -1, sets errno).

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid;

    /* execl: list of arguments */
    pid = fork();
    if (pid == 0) {
        execl("/bin/echo", "echo", "hello", "from", "execl", (char *)NULL);
        perror("execl");  /* only reached on failure */
        _exit(127);
    }
    wait(NULL);

    /* execlp: search PATH */
    pid = fork();
    if (pid == 0) {
        execlp("echo", "echo", "hello", "from", "execlp", (char *)NULL);
        perror("execlp");
        _exit(127);
    }
    wait(NULL);

    /* execv: argument vector */
    pid = fork();
    if (pid == 0) {
        char *args[] = {"ls", "-la", "/tmp", NULL};
        execv("/bin/ls", args);
        perror("execv");
        _exit(127);
    }
    wait(NULL);

    /* execve: vector + explicit environment */
    pid = fork();
    if (pid == 0) {
        char *args[] = {"env", NULL};
        char *envp[] = {"MY_VAR=hello", "PATH=/usr/bin", NULL};
        execve("/usr/bin/env", args, envp);
        perror("execve");
        _exit(127);
    }
    wait(NULL);

    return 0;
}

Key Points

•exec replaces the process image -- does NOT return on success
•Six variants: l/v (arg style), p (PATH search), e (environment)
•execve() is the only actual system call; others are wrappers
•argv[0] should be the program name by convention
•FD_CLOEXEC fds are closed; others are inherited across exec

Gotchas

•The first argument (argv[0]) is the program name, not the first real argument
•execl argument list must end with (char *)NULL -- not just NULL (variadic issue)
•If exec fails, the process continues running the old code -- always call _exit() after
•Custom signal handlers are reset to SIG_DFL across exec (but SIG_IGN is preserved)

exec replaces the current process with a new program. 6 variants: l=list args, v=vector, p=PATH search, e=explicit env. execve() is the syscall. Does NOT return on success.

•Does not return on success
•execve is the syscall; others are wrappers

#include <unistd.h>
#include <stdio.h>

int main(void) {
    execlp("ls", "ls", "-la", (char *)NULL);
    perror("exec");  /* only reached on failure */
    return 127;
}

argv[0] is the program name, not the first argument

Question 4 / 18

How do wait() and waitpid() work, and what do the status macros tell you?

wait() and waitpid() allow a parent process to collect the termination status of a child process.

Prototypes:

#include <sys/wait.h>
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);

wait() blocks until ANY child terminates. Returns the child's PID.

waitpid() is more flexible:

pid > 0: wait for specific child
pid == -1: wait for any child (like wait)
pid == 0: wait for any child in the same process group
options: WNOHANG (non-blocking), WUNTRACED (also report stopped children)

Status macros:

WIFEXITED(status) -- true if child exited normally
WEXITSTATUS(status) -- exit code (0-255), valid only if WIFEXITED
WIFSIGNALED(status) -- true if child killed by a signal
WTERMSIG(status) -- signal number that killed it
WIFSTOPPED(status) -- true if child is stopped
WSTOPSIG(status) -- signal that stopped it
WCOREDUMP(status) -- true if core dump generated (non-standard)

If a child terminates before the parent calls wait, it becomes a zombie until reaped.

Pseudo Code

1. Parent calls waitpid(child_pid, &status, 0) -- blocks
2. Or waitpid(-1, &status, WNOHANG) -- non-blocking any child
3. Check WIFEXITED(status): normal exit
   a. WEXITSTATUS(status) gives exit code
4. Check WIFSIGNALED(status): killed by signal
   a. WTERMSIG(status) gives signal number
5. Returns child PID on success, 0 if WNOHANG and no child exited, -1 on error

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();
    if (pid == 0) {
        /* Child: exit with code 42 */
        exit(42);
    }

    int status;
    pid_t w = waitpid(pid, &status, 0);
    if (w == -1) { perror("waitpid"); return 1; }

    if (WIFEXITED(status)) {
        printf("Child %d exited normally, code=%d\n",
               w, WEXITSTATUS(status));  /* code=42 */
    } else if (WIFSIGNALED(status)) {
        printf("Child %d killed by signal %d\n",
               w, WTERMSIG(status));
    }

    /* Non-blocking wait example */
    pid = fork();
    if (pid == 0) {
        sleep(2);
        _exit(0);
    }

    /* Poll for child (non-blocking) */
    w = waitpid(pid, &status, WNOHANG);
    if (w == 0)
        printf("Child %d still running\n", pid);

    /* Now block until done */
    w = waitpid(pid, &status, 0);
    printf("Child %d finished\n", w);

    return 0;
}

Child 12346 exited normally, code=42
Child 12347 still running
Child 12347 finished

Key Points

•wait() blocks for any child; waitpid() can target a specific child
•WIFEXITED/WEXITSTATUS for normal exit; WIFSIGNALED/WTERMSIG for signal death
•WNOHANG makes waitpid non-blocking (returns 0 if no child exited)
•Zombie processes exist between child exit and parent wait
•WEXITSTATUS returns only the low 8 bits (0-255)

Gotchas

•WEXITSTATUS is only valid if WIFEXITED is true -- always check WIFEXITED first
•exit(256) wraps to 0 because only 8 bits are passed (WEXITSTATUS & 0xFF)
•If you fork multiple children, you need a loop to wait for all of them
•waitpid(-1, ...) returns children in no particular order

waitpid(pid, &status, opts) waits for a child. Use WIFEXITED/WEXITSTATUS for normal exit, WIFSIGNALED/WTERMSIG for signal death. WNOHANG for non-blocking. Always check macros before extracting values.

•Check WIFEXITED before WEXITSTATUS
•WNOHANG for non-blocking wait

#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    pid_t pid = fork();
    if (pid == 0) exit(42);
    int st;
    waitpid(pid, &st, 0);
    if (WIFEXITED(st))
        printf("exit code: %d\n", WEXITSTATUS(st));  /* 42 */
    return 0;
}

exit code: 42

Exit codes wrap at 256 (only 8 bits)

Question 5 / 18

What are zombie processes, and how do you prevent them?

A zombie (defunct) process is a child that has terminated but whose parent has not yet called wait() to collect its exit status.

Why zombies exist: The kernel needs to keep the child's termination status (exit code, signal info, resource usage) available until the parent reads it. The zombie has no code, data, or stack -- just an entry in the process table.

Problem: Zombies consume a process table slot. Too many zombies (e.g., from a server that forks but never waits) can exhaust the process table, preventing new processes.

Prevention strategies:

Call wait()/waitpid(): The parent explicitly reaps each child.
SIGCHLD handler: Install a signal handler that calls waitpid(-1, ..., WNOHANG) in a loop to reap all terminated children.
Ignore SIGCHLD: signal(SIGCHLD, SIG_IGN) tells the kernel to auto-reap children (POSIX.1-2001). Children do not become zombies.
Double fork: Fork twice; the middle process exits immediately (parent waits for it). The grandchild is orphaned and adopted by init, which will reap it.

Detection: Zombies show as Z state in ps output, with <defunct> label.

Pseudo Code

Strategy 1: Explicit wait in loop
  while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { /* reap */ }

Strategy 2: SIGCHLD handler
  void handler(int sig) {
    while (waitpid(-1, NULL, WNOHANG) > 0) {}
  }
  sigaction(SIGCHLD, ...handler...)

Strategy 3: Ignore SIGCHLD
  signal(SIGCHLD, SIG_IGN)  // auto-reap

Strategy 4: Double fork
  if (fork() == 0) {        // first child
    if (fork() == 0) {      // grandchild
      // do work (adopted by init)
      _exit(0);
    }
    _exit(0);               // first child exits immediately
  }
  wait(NULL);               // reap first child

Code

#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <sys/wait.h>
#include <string.h>

/* Strategy 2: SIGCHLD handler to reap all children */
void sigchld_handler(int sig) {
    (void)sig;
    int saved_errno = errno;
    while (waitpid(-1, NULL, WNOHANG) > 0)
        ;  /* reap all available zombies */
    errno = saved_errno;
}

/* Strategy 4: Double fork */
void run_detached(void) {
    pid_t pid = fork();
    if (pid == 0) {
        /* First child */
        pid_t pid2 = fork();
        if (pid2 == 0) {
            /* Grandchild: adopted by init when first child exits */
            sleep(2);  /* simulate work */
            printf("Grandchild done (ppid=%d, likely 1 or init)\n", getppid());
            _exit(0);
        }
        _exit(0);  /* first child exits immediately */
    }
    wait(NULL);  /* reap first child (fast) */
}

int main(void) {
    /* Install SIGCHLD handler */
    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = sigchld_handler;
    sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
    sigaction(SIGCHLD, &sa, NULL);

    /* Fork some children -- handler reaps them */
    for (int i = 0; i < 3; i++) {
        if (fork() == 0) {
            printf("Child %d (pid=%d) working...\n", i, getpid());
            _exit(0);
        }
    }

    sleep(1);  /* let children finish; handler reaps them */
    printf("No zombies!\n");

    /* Double-fork example */
    run_detached();
    printf("Detached grandchild is running independently\n");

    sleep(3);
    return 0;
}

Child 0 (pid=12346) working...
Child 1 (pid=12347) working...
Child 2 (pid=12348) working...
No zombies!
Detached grandchild is running independently
Grandchild done (ppid=1, likely 1 or init)

Key Points

•Zombie = terminated child whose parent has not called wait()
•Zombies consume process table entries but no memory
•Prevent with: wait(), SIGCHLD handler, SIG_IGN, or double fork
•SIGCHLD handler must loop with WNOHANG (multiple children may exit simultaneously)
•signal(SIGCHLD, SIG_IGN) auto-reaps on POSIX systems

Gotchas

•SIGCHLD handler must save/restore errno (async-signal-safety)
•Multiple children can exit before the handler runs -- must loop with WNOHANG
•Double fork does not work if the first child fails to exit
•On Linux, zombie entries in /proc consume memory for the task_struct

Zombies are dead children not yet waited on by the parent. Prevent with: (1) waitpid() in a SIGCHLD handler, (2) signal(SIGCHLD, SIG_IGN), or (3) double-fork trick. Handler must loop with WNOHANG.

•Zombie = exited child not yet reaped
•SIGCHLD handler with WNOHANG loop prevents zombies

#include <signal.h>
#include <sys/wait.h>
#include <unistd.h>

void reap(int sig) {
    (void)sig;
    while (waitpid(-1, NULL, WNOHANG) > 0);
}

int main(void) {
    signal(SIGCHLD, reap);
    if (fork() == 0) _exit(0);  /* child exits */
    sleep(1);  /* handler reaps -- no zombie */
    return 0;
}

Must loop in handler -- multiple children can exit at once

Question 6 / 18

What are orphan processes, and how does init adopt them?

An orphan process is a running process whose parent has terminated. When the parent dies:

The kernel sets the orphan's PPID to 1 (the init/systemd process)
init automatically calls wait() for any adopted children when they terminate
This ensures orphans never become permanent zombies

Difference from zombies:

A zombie is a dead child with a live parent that has not called wait()
An orphan is a live child whose parent has died

Orphan process groups (POSIX): When a process group becomes orphaned (no process in the group has a parent in a different group in the same session), and if any member is stopped, the kernel sends SIGHUP then SIGCONT to every member of the group. This ensures stopped processes are notified.

Practical use: The double-fork technique intentionally creates an orphan to detach a long-running process from the original parent, relying on init for cleanup.

Pseudo Code

1. Parent creates child with fork()
2. Parent exits (or is killed)
3. Kernel sets child's PPID = 1 (init)
4. Child is now an orphan
5. When orphan eventually exits, init reaps it (no zombie)
6. Orphan process groups: stopped members get SIGHUP + SIGCONT

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();
    if (pid == -1) { perror("fork"); return 1; }

    if (pid == 0) {
        /* Child: will become orphan when parent exits */
        printf("Child: pid=%d, ppid=%d\n", getpid(), getppid());
        sleep(2);  /* wait for parent to exit */
        printf("Child (orphan): pid=%d, ppid=%d\n", getpid(), getppid());
        /* ppid is now 1 (init) or the subreaper PID */
        _exit(0);
    }

    /* Parent exits immediately */
    printf("Parent (pid=%d) exiting, child=%d\n", getpid(), pid);
    exit(0);  /* child becomes orphan */
    /* init (pid 1) will adopt and eventually reap the child */
}

Parent (pid=12345) exiting, child=12346
Child: pid=12346, ppid=12345
Child (orphan): pid=12346, ppid=1

Key Points

•Orphan = running child whose parent has terminated
•Kernel reparents orphans to init (PID 1)
•init always reaps its adopted children (no permanent zombies)
•Orphan process groups get SIGHUP + SIGCONT if any member is stopped
•Double-fork creates intentional orphans for daemon processes

Gotchas

•On Linux with systemd, the subreaper (PR_SET_CHILD_SUBREAPER) may adopt instead of PID 1
•Orphans continue running with their original UID/GID and environment
•An orphaned process group with stopped members gets SIGHUP before SIGCONT
•Orphans lose their controlling terminal if the parent was the session leader

Orphan = child whose parent has died. Kernel reparents it to init (PID 1), which reaps it on exit. Unlike zombies, orphans are properly cleaned up automatically.

•Reparented to init (PID 1)
•init reaps them automatically

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    if (fork() == 0) {
        sleep(2);
        printf("Orphan: ppid=%d\n", getppid());  /* 1 (init) */
        _exit(0);
    }
    exit(0);  /* parent exits; child becomes orphan */
}

systemd's subreaper may adopt instead of PID 1

Question 7 / 18

What is the difference between exit() and _exit(), and when should each be used?

Both exit() and _exit() terminate a process, but they differ in cleanup behavior.

exit() (stdlib.h):

Calls all functions registered with atexit() (in reverse order)
Flushes all open stdio streams (fflush on all FILE*)
Closes all stdio streams
Calls _exit() to terminate

_exit() (unistd.h):

Immediately terminates the process
Closes all file descriptors
Does NOT call atexit() handlers
Does NOT flush stdio buffers

When to use _exit():

In the child process after fork() if NOT calling exec()
If exit() is called in the child, it flushes the parent's stdio buffers (which were copied by fork), causing duplicate output
In signal handlers (though you should use _Exit() for C99 compliance)

_Exit() vs _exit():

_Exit() (C99, <stdlib.h>) is the standard C equivalent of POSIX _exit(). They are functionally identical.

Pseudo Code

exit(status):
  1. Call atexit handlers (LIFO order)
  2. Flush all FILE* streams
  3. Close all FILE* streams
  4. Call _exit(status)

_exit(status):
  1. Close all file descriptors
  2. Send SIGCHLD to parent
  3. If children exist, reparent to init
  4. Process becomes zombie until parent waits

Rule: child after fork should use _exit(), not exit()

Code

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

void cleanup1(void) { printf("cleanup1 called\n"); }
void cleanup2(void) { printf("cleanup2 called\n"); }

int main(void) {
    atexit(cleanup1);  /* registered first, called last */
    atexit(cleanup2);  /* registered second, called first */

    printf("Parent message (buffered)");  /* no newline = stays in buffer */

    pid_t pid = fork();
    if (pid == 0) {
        /* BAD: exit() would flush parent's buffer -> duplicate output
         * and call atexit handlers meant for parent */
        /* exit(0);  -- DO NOT DO THIS */

        /* GOOD: _exit() skips all cleanup */
        _exit(0);
    }

    wait(NULL);
    printf("\n");  /* now flush */
    /* exit() is called implicitly when main returns */
    /* Output: cleanup2, then cleanup1 */
    return 0;
}

Key Points

•exit() flushes buffers and calls atexit handlers; _exit() does not
•Child after fork should use _exit() to avoid double-flushing
•_Exit() (C99) is the portable equivalent of _exit()
•atexit handlers are called in reverse registration order
•_exit() still closes file descriptors and signals the parent

Gotchas

•Using exit() in a child after fork causes duplicate buffered output (e.g., printf without newline)
•atexit handlers are inherited by the child across fork -- exit() in child runs them too
•You can register up to 32 atexit handlers (at minimum; usually more)
•After exec(), atexit handlers from the old program are gone

exit() calls atexit handlers and flushes stdio buffers before terminating. _exit() terminates immediately (no cleanup). Use _exit() in child after fork to avoid duplicate output.

•exit = cleanup + flush; _exit = immediate termination
•Child after fork: always use _exit()

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    printf("buffered");  /* no newline */
    if (fork() == 0)
        _exit(0);  /* no flush; exit() would duplicate "buffered" */
    wait(NULL);
    printf("\n");  /* flush once */
    return 0;
}

buffered

exit() in forked child causes duplicate buffered output

Question 8 / 18

What are process groups and sessions, and how do setpgid() and setsid() work?

UNIX organizes processes into a hierarchy: sessions contain process groups, which contain processes.

Process group:

A collection of related processes (e.g., ls | sort | head is one process group)
Identified by a process group ID (PGID) = PID of the group leader
Signals can be sent to the entire group: kill(-pgid, signal)
The shell uses process groups for job control (foreground/background jobs)

Session:

A collection of process groups (typically one login session)
Created by setsid() -- the calling process becomes the session leader
Has at most one controlling terminal
The session leader is the only process that can acquire a controlling terminal

APIs:

getpgrp() / getpgid(pid) -- get process group ID
setpgid(pid, pgid) -- set process group ID
getsid(pid) -- get session ID
setsid() -- create a new session (caller becomes session leader)

setsid() rules:

The calling process must NOT be a process group leader
It becomes: session leader + process group leader + has no controlling terminal
Common pattern: fork() then setsid() in the child (child is not a group leader)

Pseudo Code

Process hierarchy:
  Session (SID)
    |- Foreground process group (PGID)
    |    |- process 1
    |    |- process 2
    |- Background process group (PGID)
         |- process 3

setsid():
  1. Must not be a process group leader
  2. Creates new session (caller = session leader)
  3. Creates new process group (caller = group leader)
  4. No controlling terminal

setpgid(pid, pgid):
  - Move process pid into group pgid
  - Can only move own children (before they exec)

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    printf("Parent: pid=%d, pgid=%d, sid=%d\n",
           getpid(), getpgrp(), getsid(0));

    pid_t pid = fork();
    if (pid == 0) {
        printf("Child before setsid: pid=%d, pgid=%d, sid=%d\n",
               getpid(), getpgrp(), getsid(0));

        /* Create new session */
        pid_t newsid = setsid();
        if (newsid == -1) {
            perror("setsid");
        } else {
            printf("Child after setsid:  pid=%d, pgid=%d, sid=%d\n",
                   getpid(), getpgrp(), getsid(0));
            /* pid == pgid == sid (session leader) */
        }

        _exit(0);
    }

    wait(NULL);

    /* Process group example */
    pid_t child1 = fork();
    if (child1 == 0) { sleep(1); _exit(0); }

    pid_t child2 = fork();
    if (child2 == 0) { sleep(1); _exit(0); }

    /* Put both children in the same process group */
    setpgid(child1, child1);  /* child1 is group leader */
    setpgid(child2, child1);  /* child2 joins child1's group */

    printf("child1 pgid=%d, child2 pgid=%d\n",
           getpgid(child1), getpgid(child2));  /* both = child1 */

    wait(NULL); wait(NULL);
    return 0;
}

Parent: pid=12345, pgid=12345, sid=12340
Child before setsid: pid=12346, pgid=12345, sid=12340
Child after setsid:  pid=12346, pgid=12346, sid=12346
child1 pgid=12347, child2 pgid=12347

Key Points

•Process group: related processes (e.g., a pipeline); PGID = leader's PID
•Session: collection of process groups; created by setsid()
•setsid() makes caller the session + group leader with no controlling terminal
•kill(-pgid, sig) sends signal to entire process group
•Shell uses process groups for job control (fg/bg)

Gotchas

•setsid() fails if the caller is already a process group leader -- fork first
•setpgid() can only move a child before it calls exec()
•A session leader that opens a terminal may acquire it as a controlling terminal
•SIGHUP is sent to the foreground process group when the session leader (terminal) dies

Process group = related processes (pipeline). Session = collection of groups. setsid() creates a new session (no controlling terminal). setpgid() moves processes between groups. Used for job control and daemons.

•setsid creates new session with no controlling terminal
•kill(-pgid, sig) sends to entire group

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    if (fork() == 0) {
        setsid();  /* new session, no terminal */
        printf("New session: pid=%d sid=%d\n", getpid(), getsid(0));
        _exit(0);
    }
    wait(NULL);
    return 0;
}

New session: pid=12346 sid=12346

setsid fails if caller is already a process group leader

Question 9 / 18

How do you create a daemon process in C (the double-fork pattern)?

A daemon is a long-running background process with no controlling terminal. The classic daemon creation pattern involves these steps:

1. First fork + parent exit:

Creates a child that is NOT a process group leader
Allows the shell to regain the prompt

2. setsid():

Creates a new session (child becomes session leader)
Creates a new process group
Detaches from the controlling terminal

3. Second fork + first child exit (optional but recommended):

The grandchild is NOT a session leader
Therefore it can NEVER accidentally acquire a controlling terminal by opening a terminal device

4. chdir("/"):

Prevents the daemon from holding a mount point busy

5. umask(0):

Clear the umask so file creation modes are fully controlled

6. Redirect stdin/stdout/stderr to /dev/null:

Close inherited fds and redirect standard ones

Modern systems also have daemon() (BSD) and systemd integration, but understanding the manual method is essential for interviews.

Pseudo Code

1. fork() -- parent exits, child continues
2. setsid() -- new session, no controlling terminal
3. fork() again -- first child exits, grandchild continues
4. chdir("/") -- don't hold a mount point busy
5. umask(0) -- full control over file permissions
6. Close all fds; open /dev/null for stdin/stdout/stderr
7. Run daemon main loop

Why double fork:
- After setsid, process is session leader
- Session leader CAN acquire a terminal by opening one
- Second fork: grandchild is NOT session leader -> can NEVER acquire terminal

Code

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/resource.h>

void daemonize(void) {
    /* Step 1: First fork */
    pid_t pid = fork();
    if (pid < 0) { perror("fork"); exit(1); }
    if (pid > 0) exit(0);  /* parent exits */

    /* Step 2: New session */
    if (setsid() == -1) { perror("setsid"); exit(1); }

    /* Step 3: Second fork (prevent acquiring terminal) */
    pid = fork();
    if (pid < 0) { perror("fork"); exit(1); }
    if (pid > 0) _exit(0);  /* first child exits */

    /* Step 4: Change working directory */
    chdir("/");

    /* Step 5: Clear umask */
    umask(0);

    /* Step 6: Close all open file descriptors */
    struct rlimit rl;
    getrlimit(RLIMIT_NOFILE, &rl);
    for (rlim_t i = 0; i < rl.rlim_cur; i++)
        close((int)i);

    /* Step 7: Redirect stdin/stdout/stderr to /dev/null */
    int fd0 = open("/dev/null", O_RDWR);  /* stdin = fd 0 */
    dup2(fd0, STDOUT_FILENO);              /* stdout = fd 1 */
    dup2(fd0, STDERR_FILENO);              /* stderr = fd 2 */
}

int main(void) {
    daemonize();

    /* Daemon main loop */
    for (;;) {
        /* Do daemon work here */
        sleep(30);
    }

    return 0;  /* unreachable */
}

Key Points

•Double fork: ensures the daemon can never acquire a controlling terminal
•setsid() creates a new session detached from the terminal
•chdir("/") prevents holding mount points busy
•Redirect stdin/stdout/stderr to /dev/null
•umask(0) gives full control over created file permissions

Gotchas

•Single fork without the second fork allows the session leader to accidentally acquire a terminal
•Forgetting to close inherited fds can cause resource leaks and hold files open
•BSD daemon() function exists but is not portable and may not do the second fork
•On systemd, Type=forking services need a PID file; Type=simple is simpler

Daemon pattern: (1) fork + parent exit, (2) setsid(), (3) fork again + exit, (4) chdir("/"), (5) umask(0), (6) redirect std fds to /dev/null. Double fork prevents accidentally acquiring a terminal.

•Double fork prevents terminal acquisition
•setsid detaches from controlling terminal

#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/stat.h>

void daemonize(void) {
    if (fork() > 0) exit(0);   /* parent exits */
    setsid();                   /* new session */
    if (fork() > 0) _exit(0);  /* prevent terminal acquisition */
    chdir("/");
    umask(0);
    int fd = open("/dev/null", O_RDWR);
    dup2(fd, 0); dup2(fd, 1); dup2(fd, 2);
    if (fd > 2) close(fd);
}

Single fork still allows session leader to acquire terminal

Question 10 / 18

How do atexit() handlers work, and in what order are they called?

atexit() registers a function to be called automatically when the process terminates normally (via exit() or returning from main()).

Prototype:

#include <stdlib.h>
int atexit(void (*function)(void));

Calling order: Handlers are called in reverse registration order (LIFO -- last registered, first called).

When they are called:

On exit() call
On return from main()
NOT on _exit() / _Exit()
NOT on abnormal termination (signal like SIGKILL, SIGSEGV without handler)

Use cases:

Cleaning up temporary files
Releasing shared resources (shared memory, semaphores)
Flushing logs
Closing database connections

POSIX guarantees at least 32 atexit handlers can be registered. The function must take no arguments and return void.

Pseudo Code

1. atexit(cleanup_A)  -- registered first
2. atexit(cleanup_B)  -- registered second
3. atexit(cleanup_C)  -- registered third
4. exit(0) or return from main
5. cleanup_C called first (LIFO)
6. cleanup_B called second
7. cleanup_A called last
8. After all handlers: stdio buffers flushed, then _exit()

Code

#include <stdlib.h>
#include <stdio.h>

void cleanup_temp(void) {
    printf("1. Removing temporary files\n");
    /* unlink("/tmp/myapp.tmp"); */
}

void flush_logs(void) {
    printf("2. Flushing log buffers\n");
}

void close_db(void) {
    printf("3. Closing database connection\n");
}

int main(void) {
    /* Register in order: temp, logs, db */
    atexit(cleanup_temp);  /* called LAST */
    atexit(flush_logs);    /* called second */
    atexit(close_db);      /* called FIRST (LIFO) */

    printf("Doing work...\n");

    /* exit(0) or returning from main triggers atexit handlers */
    return 0;
    /* Output order:
       3. Closing database connection
       2. Flushing log buffers
       1. Removing temporary files */
}

Doing work...
3. Closing database connection
2. Flushing log buffers
1. Removing temporary files

Key Points

•atexit registers cleanup functions called on normal termination
•Called in reverse registration order (LIFO)
•Called by exit() and return from main, NOT by _exit()
•At least 32 handlers can be registered (POSIX minimum)
•Handler functions take no args and return void

Gotchas

•_exit() and _Exit() skip atexit handlers entirely
•Signal-caused termination (SIGKILL, SIGSEGV) does NOT call atexit handlers
•Calling exit() inside an atexit handler is undefined behavior
•After fork(), child inherits all registered atexit handlers -- use _exit() in child

atexit(fn) registers a cleanup function called on exit() or return from main(). Called in reverse order (LIFO). NOT called by _exit() or signal termination.

•LIFO order (last registered = first called)
•Skipped by _exit() and signal kills

#include <stdlib.h>
#include <stdio.h>

void cleanup(void) { printf("cleaning up\n"); }

int main(void) {
    atexit(cleanup);  /* called when main returns */
    printf("working...\n");
    return 0;  /* triggers cleanup() */
}

working...
cleaning up

Calling exit() inside an atexit handler is undefined behavior

Question 11 / 18

How do getenv(), setenv(), and putenv() manage environment variables?

Every process has an environment -- a list of NAME=VALUE strings accessible via the global extern char **environ.

APIs:

#include <stdlib.h>
char *getenv(const char *name);           /* returns value or NULL */
int setenv(const char *name, const char *value, int overwrite);
int unsetenv(const char *name);
int putenv(char *string);  /* string format: "NAME=VALUE" */

getenv(): Returns pointer to the value (not the NAME= part), or NULL if not found. The returned pointer should NOT be modified.

setenv(): Adds or modifies a variable. If overwrite is 0 and the variable exists, it is not changed. Always allocates a copy of the string.

putenv(): Takes a NAME=VALUE string and adds it directly (no copy). If you modify or free the string, the environment is corrupted.

unsetenv(): Removes a variable.

Inheritance: Environment is inherited by child processes across fork() and exec(). execle()/execve() can pass an explicit environment.

Pseudo Code

1. getenv("HOME") -> returns "/home/user" or NULL
2. setenv("MY_VAR", "value", 1) -> adds/overwrites
3. putenv("MY_VAR=value") -> adds directly (no copy)
4. unsetenv("MY_VAR") -> removes
5. extern char **environ -> direct access to entire environment
6. Environment inherited across fork and exec

Code

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    /* Read environment variable */
    const char *home = getenv("HOME");
    printf("HOME = %s\n", home ? home : "(not set)");

    /* Set a new variable */
    if (setenv("MY_APP_MODE", "production", 1) == -1)
        perror("setenv");
    printf("MY_APP_MODE = %s\n", getenv("MY_APP_MODE"));

    /* Overwrite control */
    setenv("MY_APP_MODE", "debug", 0);  /* overwrite=0: no change */
    printf("MY_APP_MODE (no overwrite) = %s\n", getenv("MY_APP_MODE"));
    /* Still "production" */

    setenv("MY_APP_MODE", "debug", 1);  /* overwrite=1: changed */
    printf("MY_APP_MODE (overwrite) = %s\n", getenv("MY_APP_MODE"));
    /* Now "debug" */

    /* Remove a variable */
    unsetenv("MY_APP_MODE");
    printf("After unsetenv: %s\n",
           getenv("MY_APP_MODE") ? getenv("MY_APP_MODE") : "(not set)");

    /* Print all environment (via extern environ) */
    extern char **environ;
    printf("\nFirst 3 env vars:\n");
    for (int i = 0; i < 3 && environ[i]; i++)
        printf("  %s\n", environ[i]);

    return 0;
}

HOME = /home/user
MY_APP_MODE = production
MY_APP_MODE (no overwrite) = production
MY_APP_MODE (overwrite) = debug
After unsetenv: (not set)

First 3 env vars:
  TERM_PROGRAM=Apple_Terminal
  SHELL=/bin/zsh
  HOME=/home/user

Key Points

•getenv returns a pointer to the value string (or NULL)
•setenv copies the string; putenv uses the original (no copy)
•Environment is inherited across fork and exec
•extern char **environ gives direct access to the full environment
•unsetenv removes a variable

Gotchas

•putenv does not copy the string -- modifying or freeing it corrupts the environment
•getenv is not thread-safe on some systems (returns pointer to internal buffer)
•setenv allocates memory that is never freed (small leak by design)
•Modifying environ directly can cause memory corruption if not careful

getenv(name) reads env vars. setenv(name, value, overwrite) sets them (copies string). putenv("K=V") adds directly (no copy). unsetenv(name) removes. Inherited by child processes.

•setenv copies; putenv does not
•Inherited across fork/exec

#include <stdlib.h>
#include <stdio.h>

int main(void) {
    printf("HOME=%s\n", getenv("HOME"));
    setenv("MY_VAR", "hello", 1);
    printf("MY_VAR=%s\n", getenv("MY_VAR"));
    unsetenv("MY_VAR");
    return 0;
}

HOME=/home/user
MY_VAR=hello

putenv's string must not be freed or modified

Question 12 / 18

Why is system() considered dangerous, and what are the alternatives?

system() executes a shell command by calling /bin/sh -c command.

Prototype:

#include <stdlib.h>
int system(const char *command);

How it works: fork() + exec("/bin/sh", "-c", command) + waitpid()

Why it is dangerous:

Shell injection: If the command string includes user input, an attacker can inject shell metacharacters:

char cmd[256];
sprintf(cmd, "ls %s", user_input);  /* user_input = "; rm -rf /" */
system(cmd);  /* executes: ls ; rm -rf / */

Environment manipulation: The shell inherits PATH, IFS, LD_PRELOAD etc. Attackers can manipulate these to execute arbitrary code.
Signal handling: system() blocks SIGCHLD and ignores SIGINT/SIGQUIT, which can cause unexpected behavior.
Performance: Spawns a shell process for every call.

Safer alternatives:

fork() + exec() with explicit arguments (no shell parsing)
posix_spawn() for simpler process creation
Direct system calls instead of shelling out (e.g., rename() instead of system("mv ..."))

Pseudo Code

DANGEROUS:
  system("ls " + user_input)  -- shell interprets metacharacters

SAFE:
  fork()
  if child:
    execl("/bin/ls", "ls", user_input, NULL)  -- no shell, no injection
  waitpid()

Or use direct syscalls:
  Instead of system("rm file") -> unlink("file")
  Instead of system("mv a b")  -> rename("a", "b")
  Instead of system("mkdir d") -> mkdir("d", 0755)

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>

/* DANGEROUS: shell injection possible */
void unsafe_list(const char *dir) {
    char cmd[256];
    snprintf(cmd, sizeof(cmd), "ls -la %s", dir);
    system(cmd);  /* if dir = "; cat /etc/shadow" -> BAD */
}

/* SAFE: fork+exec, no shell involvement */
int safe_list(const char *dir) {
    pid_t pid = fork();
    if (pid == -1) { perror("fork"); return -1; }

    if (pid == 0) {
        /* dir is passed as a single argument, no shell parsing */
        execl("/bin/ls", "ls", "-la", dir, (char *)NULL);
        perror("exec");
        _exit(127);
    }

    int status;
    waitpid(pid, &status, 0);
    return WIFEXITED(status) ? WEXITSTATUS(status) : -1;
}

int main(void) {
    /* This is safe even with malicious input */
    safe_list("/tmp");

    /* Prefer direct syscalls when possible */
    /* Instead of system("mkdir /tmp/mydir"): */
    mkdir("/tmp/mydir", 0755);

    return 0;
}

Key Points

•system() invokes /bin/sh -c, which parses shell metacharacters
•Shell injection is the primary security risk
•fork+exec with explicit args avoids shell parsing entirely
•Use direct syscalls (rename, unlink, mkdir) instead of shelling out
•system() also has performance overhead (spawns a shell)

Gotchas

•system() in a setuid program is extremely dangerous -- shell inherits elevated privileges
•Even quoting or escaping is fragile -- fork+exec is always safer
•system() blocks SIGCHLD, which can interfere with other child management
•system(NULL) returns non-zero if a shell is available (portability check)

system() runs a shell command -- dangerous due to shell injection with user input. Use fork() + exec() with explicit arguments instead. Or use direct syscalls (rename(), unlink(), mkdir()).

•system() = shell injection risk
•fork+exec with explicit args is safe

#include <unistd.h>
#include <sys/wait.h>

/* Safe: no shell, no injection */
int safe_run(const char *prog, const char *arg) {
    pid_t pid = fork();
    if (pid == 0) {
        execl(prog, prog, arg, (char *)NULL);
        _exit(127);
    }
    int st;
    waitpid(pid, &st, 0);
    return WEXITSTATUS(st);
}

system() in setuid programs is extremely dangerous

Question 13 / 18

What is vfork(), and why is it mostly obsolete?

vfork() was created as an optimization for the fork() + exec() pattern before copy-on-write was available.

How vfork() differs from fork():

The child shares the parent's address space (no copy, no COW)
The parent is suspended until the child calls exec() or _exit()
The child must NOT:
- Modify any variables (would corrupt parent's state)
- Call any functions that modify state
- Return from the function that called vfork()
- Call exit() (would run atexit handlers in shared space)

Historical motivation: Before COW, fork() physically copied the entire address space. For the common fork() + exec() pattern, this was wasteful since exec() immediately discards the copy. vfork() avoided the copy entirely.

Current status:

With modern COW fork, vfork() provides minimal benefit
It is error-prone and hard to use correctly
POSIX.1-2008 marked vfork() as obsolescent
posix_spawn() is the modern replacement for the fork+exec pattern
Some embedded/real-time systems without MMU still use vfork

Pseudo Code

vfork():
  1. Child shares parent's address space (no copy)
  2. Parent is BLOCKED until child calls exec() or _exit()
  3. Child MUST NOT modify variables, call functions, or return
  4. Only two legal operations: exec() or _exit()

fork() with COW:
  1. Child gets COW copy (fast, safe)
  2. Parent continues immediately
  3. Child can do anything

Conclusion: use fork() (with COW) or posix_spawn()

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>

int main(void) {
    /* vfork example -- extremely restricted child */
    pid_t pid = vfork();
    if (pid == -1) {
        perror("vfork");
        return 1;
    }

    if (pid == 0) {
        /* Child: ONLY exec() or _exit() is safe */
        /* DO NOT modify variables, call printf, etc. */
        execlp("echo", "echo", "hello from vfork child", (char *)NULL);
        _exit(127);  /* only if exec fails */
    }

    /* Parent resumes here after child execs or exits */
    int status;
    waitpid(pid, &status, 0);
    printf("Child finished\n");

    /* Modern alternative: posix_spawn */
    /* posix_spawn() combines fork+exec safely and efficiently */

    return 0;
}

hello from vfork child
Child finished

Key Points

•vfork shares the parent's address space (no copy at all)
•Parent is blocked until child calls exec() or _exit()
•Child must NOT modify variables, call functions, or return
•Created before COW made fork() efficient
•posix_spawn() is the modern replacement

Gotchas

•Modifying ANY variable in vfork child corrupts the parent's state
•Calling exit() (not _exit) in vfork child runs atexit handlers in shared space
•Returning from the function that called vfork is undefined behavior
•vfork is marked obsolescent in POSIX.1-2008

vfork() shares parent's address space (no copy). Parent blocked until child calls exec() or _exit(). Mostly obsolete since COW makes fork() efficient. Use fork() or posix_spawn() instead.

•Shares parent address space (dangerous)
•Obsolete: use fork() with COW or posix_spawn()

#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = vfork();
    if (pid == 0) {
        /* ONLY exec or _exit is safe */
        execlp("echo", "echo", "vfork child", (char *)NULL);
        _exit(127);
    }
    wait(NULL);
    return 0;
}

Modifying variables in vfork child corrupts parent

Question 14 / 18

What does the process memory layout look like (text, data, BSS, heap, stack)?

A running C process has a well-defined memory layout (low to high addresses on most architectures):

1. Text segment (code):

Contains the executable machine instructions
Read-only and sharable (multiple instances of the same program share it)
Attempting to write causes SIGSEGV

2. Initialized data segment (.data):

Global and static variables with explicit initialization
e.g., int x = 42; at file scope, static int y = 10;

3. Uninitialized data segment (BSS -- Block Started by Symbol):

Global and static variables without explicit initialization (or initialized to 0)
The kernel initializes this to zero before the program starts
Does not take space in the executable file (just the size is stored)
e.g., int arr[1000]; at file scope

4. Heap:

Dynamic memory allocated by malloc(), calloc(), realloc()
Grows upward (toward higher addresses)
Managed by the C library (using brk()/sbrk() or mmap())

5. Stack:

Local variables, function parameters, return addresses
Grows downward (toward lower addresses)
Each function call creates a stack frame
Limited size (typically 8MB default, controlled by RLIMIT_STACK)

6. Kernel space (above stack):

Not accessible to user-mode code

Between heap and stack is unmapped memory. If they collide, stack overflow occurs.

Pseudo Code

High addresses:
  +------------------+
  | Kernel space     |  (not accessible)
  +------------------+
  | Stack            |  grows DOWN (local vars, frames)
  |       |          |
  |       v          |
  |                  |
  |       ^          |
  |       |          |
  | Heap             |  grows UP (malloc)
  +------------------+
  | BSS (.bss)       |  uninitialized globals (zeroed)
  +------------------+
  | Data (.data)     |  initialized globals
  +------------------+
  | Text (.text)     |  code (read-only)
  +------------------+
Low addresses

Code

#include <stdio.h>
#include <stdlib.h>

/* Text segment: function code */
void func(void) { printf("in func\n"); }

/* Initialized data segment */
int global_init = 42;
static int static_init = 10;

/* BSS segment (uninitialized, zeroed) */
int global_uninit;
static int static_uninit;
int large_array[10000];  /* in BSS, does not bloat executable */

int main(void) {
    /* Stack */
    int local_var = 99;
    char local_arr[128];

    /* Heap */
    int *heap_ptr = malloc(sizeof(int) * 100);

    printf("Text:   func    @ %p\n", (void *)func);
    printf("Data:   global  @ %p (value=%d)\n",
           (void *)&global_init, global_init);
    printf("BSS:    uninit  @ %p (value=%d)\n",
           (void *)&global_uninit, global_uninit);  /* 0 */
    printf("Heap:   malloc  @ %p\n", (void *)heap_ptr);
    printf("Stack:  local   @ %p\n", (void *)&local_var);

    /* Typical address order: text < data < bss < heap <<< stack */
    printf("\nNote: heap grows up, stack grows down\n");

    free(heap_ptr);
    return 0;
}

Text:   func    @ 0x401136
Data:   global  @ 0x404030 (value=42)
BSS:    uninit  @ 0x404034 (value=0)
Heap:   malloc  @ 0x1e50260
Stack:  local   @ 0x7ffd5e8a3000

Note: heap grows up, stack grows down

Key Points

•Five segments: text (code), data (initialized), BSS (uninitialized), heap, stack
•Text is read-only and shareable between processes
•BSS is zeroed by kernel and does not take space in the executable file
•Heap grows up (malloc); stack grows down (function calls)
•Stack overflow occurs when stack meets heap or exceeds RLIMIT_STACK

Gotchas

•BSS variables are guaranteed to be zero; local stack variables are NOT initialized
•Stack size is limited (often 8MB) -- large local arrays can cause stack overflow
•The heap may use mmap for large allocations, placing them outside the traditional heap area
•ASLR randomizes the base addresses of stack, heap, and libraries for security

Process layout (low to high): text (code, read-only) -> data (initialized globals) -> BSS (uninitialized globals, zeroed) -> heap (malloc, grows up) -> stack (locals, grows down). BSS does not take space in the executable.

•text < data < BSS < heap ... stack
•BSS zeroed; stack variables NOT initialized

#include <stdio.h>
#include <stdlib.h>

int global = 42;      /* data segment */
int uninit;           /* BSS (zeroed) */

int main(void) {
    int local = 1;                     /* stack */
    int *p = malloc(sizeof(int));      /* heap */
    printf("data=%p bss=%p heap=%p stack=%p\n",
           (void*)&global, (void*)&uninit, (void*)p, (void*)&local);
    free(p);
    return 0;
}

data=0x404030 bss=0x404034 heap=0x1e50260 stack=0x7ffd5e8a3000

Large local arrays cause stack overflow

Question 15 / 18

What race conditions can occur with fork(), and how do you handle them?

After fork(), the order of execution between parent and child is indeterminate. This creates several potential race conditions:

1. Output interleaving: Both parent and child writing to the same fd (inherited, shared offset) can produce interleaved output.

2. File operation races: Parent creates a file; child tries to read it. If child runs first, the file may not exist yet.

3. Variable state assumptions: Assumming the child runs before the parent (or vice versa) is a bug. The scheduler decides.

4. Signal handling races: Parent installs signal handler after fork -- child may not have it. Or parent sends signal to child before child installs its handler.

Synchronization techniques:

Pipes: Parent/child communicate via a pipe. One blocks on read() until the other writes.
Signals: Parent sends SIGUSR1 to child (or vice versa) with kill(), child waits with sigsuspend().
wait(): Parent calls wait() to synchronize after child completes.
Semaphores/shared memory: For more complex synchronization.

The APUE book recommends a TELL_WAIT/TELL_PARENT/TELL_CHILD/WAIT_PARENT/WAIT_CHILD pattern using either signals or pipes.

Pseudo Code

RACE (broken):
  fork()
  parent: create file -> write data
  child:  open file -> read data
  Bug: child might run first, file does not exist yet

FIX with pipe synchronization:
  pipe(fd)
  fork()
  parent: create file -> write(fd[1], "go", 2)  // signal child
  child:  read(fd[0], buf, 2) -> open file -> read data
  Child blocks until parent signals readiness

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

/* Pipe-based parent-child synchronization */
static int pfd_parent[2];  /* parent signals child */
static int pfd_child[2];   /* child signals parent */

void tell_wait(void) {
    pipe(pfd_parent);
    pipe(pfd_child);
}

void tell_child(void) {
    write(pfd_parent[1], "c", 1);
}

void wait_parent(void) {
    char c;
    read(pfd_parent[0], &c, 1);  /* blocks until parent signals */
}

void tell_parent(void) {
    write(pfd_child[1], "p", 1);
}

void wait_child(void) {
    char c;
    read(pfd_child[0], &c, 1);  /* blocks until child signals */
}

int main(void) {
    tell_wait();

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: wait for parent to be ready */
        wait_parent();
        printf("Child: parent is ready, proceeding\n");
        tell_parent();  /* signal parent we are done */
        _exit(0);
    }

    /* Parent: do setup work */
    printf("Parent: doing setup...\n");
    /* ... create files, initialize state ... */
    tell_child();   /* signal child that setup is complete */
    wait_child();   /* wait for child to finish */
    printf("Parent: child is done\n");

    wait(NULL);
    close(pfd_parent[0]); close(pfd_parent[1]);
    close(pfd_child[0]); close(pfd_child[1]);
    return 0;
}

Parent: doing setup...
Child: parent is ready, proceeding
Parent: child is done

Key Points

•Execution order after fork() is indeterminate -- never assume an order
•Shared file descriptors mean shared offsets -- writes can interleave
•Pipes are the simplest synchronization mechanism between parent and child
•APUE TELL_WAIT pattern provides clean parent-child coordination
•Signals (SIGUSR1/SIGUSR2) can also synchronize but are trickier

Gotchas

•Assuming the child always runs first (or parent) is a portability bug
•On Linux, the parent tends to run first (but this is not guaranteed)
•Shared stdio buffers after fork can cause duplicate output if not flushed
•Using sleep() for synchronization is a race condition (timing-dependent)

After fork(), parent/child execution order is undefined. Synchronize with pipes (read blocks until write), signals, or wait(). Never assume an order. Never use sleep() for synchronization.

•Execution order is indeterminate after fork
•Pipes provide blocking synchronization

#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>

int main(void) {
    int pfd[2];
    pipe(pfd);
    if (fork() == 0) {
        char c;
        read(pfd[0], &c, 1);  /* block until parent signals */
        printf("Child: parent is ready\n");
        _exit(0);
    }
    printf("Parent: setup done\n");
    write(pfd[1], "g", 1);  /* signal child */
    wait(NULL);
    return 0;
}

Parent: setup done
Child: parent is ready

sleep() for synchronization is a race condition

Question 16 / 18

How would you implement a simple shell in C?

A basic shell follows a simple loop: read, parse, fork, exec, wait (RPFEW).

Core components:

Read: Get a command line from the user (fgets() or readline())
Parse: Tokenize the line into command and arguments
Fork: Create a child process
Exec: In the child, replace the process image with the command
Wait: Parent waits for the child to complete

Additional features for a real shell:

Built-in commands (cd, exit, export) -- these cannot be external
Background execution (&) -- do not wait for child
I/O redirection (>, <, >>) -- use dup2() before exec
Pipes (|) -- use pipe() + dup2() to connect commands
Signal handling -- ignore SIGINT/SIGTSTP in the shell, reset in children

cd must be a builtin because chdir() in a child process does not affect the parent (the shell).

Pseudo Code

loop:
  1. Print prompt
  2. Read line (fgets or readline)
  3. If line is empty or EOF, continue/exit
  4. Parse into argv[] tokens
  5. Check for builtins (cd, exit)
  6. Fork
  7. Child: exec(argv[0], argv)
  8. Parent: waitpid(child)
  9. Repeat

For pipes:  cmd1 | cmd2
  pipe(pfd)
  fork child1: dup2(pfd[1], STDOUT); exec(cmd1)
  fork child2: dup2(pfd[0], STDIN);  exec(cmd2)
  close pipe in parent
  wait for both children

Code

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>

#define MAX_ARGS 64
#define MAX_LINE 1024

int parse_line(char *line, char **argv) {
    int argc = 0;
    char *token = strtok(line, " \t\n");
    while (token != NULL && argc < MAX_ARGS - 1) {
        argv[argc++] = token;
        token = strtok(NULL, " \t\n");
    }
    argv[argc] = NULL;
    return argc;
}

int main(void) {
    char line[MAX_LINE];
    char *argv[MAX_ARGS];

    for (;;) {
        printf("mysh> ");
        fflush(stdout);

        if (fgets(line, sizeof(line), stdin) == NULL)
            break;  /* EOF */

        int argc = parse_line(line, argv);
        if (argc == 0) continue;

        /* Builtin: cd */
        if (strcmp(argv[0], "cd") == 0) {
            if (argv[1] == NULL)
                chdir(getenv("HOME"));
            else if (chdir(argv[1]) == -1)
                perror("cd");
            continue;
        }

        /* Builtin: exit */
        if (strcmp(argv[0], "exit") == 0)
            break;

        /* External command: fork + exec */
        pid_t pid = fork();
        if (pid == -1) {
            perror("fork");
            continue;
        }

        if (pid == 0) {
            /* Child: execute command */
            execvp(argv[0], argv);
            fprintf(stderr, "mysh: %s: command not found\n", argv[0]);
            _exit(127);
        }

        /* Parent: wait for child */
        int status;
        waitpid(pid, &status, 0);
    }

    printf("\n");
    return 0;
}

Key Points

•Shell loop: read -> parse -> fork -> exec -> wait
•cd must be a builtin (chdir in child does not affect parent)
•execvp searches PATH for the command
•Child calls _exit(127) if exec fails (convention for command not found)
•Pipes use pipe() + dup2() to connect stdout of one command to stdin of next

Gotchas

•strtok modifies the input string and is not reentrant -- use strtok_r for thread safety
•The shell must handle SIGINT differently from children (ignore in shell, default in child)
•Background processes need SIGCHLD handling to avoid zombies
•I/O redirection must be done after fork but before exec

Shell = loop of: read line, parse into argv, fork, child execs, parent waits. cd and exit must be builtins. Use execvp() for PATH search. Pipes: pipe() + dup2() between forked children.

•Read-parse-fork-exec-wait loop
•cd must be a builtin

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/wait.h>
#include <stdlib.h>

int main(void) {
    char line[256];
    while (printf("$ "), fgets(line, 256, stdin)) {
        line[strcspn(line, "\n")] = '\0';
        if (!*line) continue;
        if (fork() == 0) {
            execlp(line, line, (char *)NULL);
            _exit(127);
        }
        wait(NULL);
    }
    return 0;
}

Shell must handle signals differently from children

Question 17 / 18

What are getpid() and getppid(), and how does the process ID hierarchy work?

Every UNIX process has a unique process ID (PID) and knows its parent's PID.

Functions:

#include <unistd.h>
pid_t getpid(void);   /* always succeeds, returns current PID */
pid_t getppid(void);  /* always succeeds, returns parent PID */

PID properties:

PIDs are non-negative integers (typically 16-bit or 32-bit)
PID 0 = swapper/scheduler (kernel process)
PID 1 = init (or systemd) -- ancestor of all user processes
PIDs are assigned incrementally and wrap around
A PID is guaranteed unique while the process exists (reused after termination)

Process hierarchy:

Every process (except PID 0) has a parent
When a parent dies, children are reparented to init (PID 1)
getppid() in the child of a dead parent returns 1
The process tree can be viewed with pstree command

pid_t type:

Defined in <sys/types.h>
Signed integer (negative values used for process group IDs in some APIs)
kill(-pgid, sig) sends to a process group (negative PID)

Pseudo Code

1. getpid() returns the caller's PID (never fails)
2. getppid() returns the parent's PID (never fails)
3. After fork(): child getppid() == parent getpid()
4. If parent dies: child getppid() returns 1 (init)
5. PID 0 = kernel scheduler
6. PID 1 = init (reaps orphans)

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    printf("Current process: pid=%d, ppid=%d\n", getpid(), getppid());

    pid_t child = fork();
    if (child == 0) {
        printf("Child: pid=%d, ppid=%d\n", getpid(), getppid());
        /* getppid() == parent's getpid() */
        _exit(0);
    }

    printf("Parent: my pid=%d, child pid=%d\n", getpid(), child);
    waitpid(child, NULL, 0);

    /* Demonstrate orphan reparenting */
    pid_t orphan = fork();
    if (orphan == 0) {
        sleep(1);  /* let parent exit */
        printf("Orphan: pid=%d, ppid=%d (should be 1 or subreaper)\n",
               getpid(), getppid());
        _exit(0);
    }
    /* Parent does not wait -- orphan gets reparented to init */

    return 0;
}

Current process: pid=12345, ppid=12300
Parent: my pid=12345, child pid=12346
Child: pid=12346, ppid=12345

Key Points

•getpid() and getppid() always succeed (no error return)
•PID 0 = kernel; PID 1 = init (ancestor of all user processes)
•PIDs are reused after process termination
•Orphaned processes have ppid = 1 (or subreaper PID)
•pid_t is signed to support negative values in kill(-pgid, sig)

Gotchas

•getpid() in a multithreaded program returns the thread group leader's PID (TGID), not the thread's tid
•PID wrap-around can cause a new process to get an old PID -- never cache PIDs long-term
•Linux's pid_max is configurable (/proc/sys/kernel/pid_max, default 32768)
•After fork, getppid() in the child may return a stale value if parent exits before child calls it

getpid() returns current PID, getppid() returns parent's PID. Both always succeed. PID 0 = kernel, PID 1 = init. Orphans get ppid=1.

•Always succeed, no error return
•PID 1 = init, adopts orphans

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

int main(void) {
    printf("pid=%d ppid=%d\n", getpid(), getppid());
    if (fork() == 0) {
        printf("child: pid=%d ppid=%d\n", getpid(), getppid());
        _exit(0);
    }
    wait(NULL);
    return 0;
}

pid=12345 ppid=12300
child: pid=12346 ppid=12345

In threads, getpid() returns TGID, not thread tid

Question 18 / 18

What is posix_spawn(), and when should you use it instead of fork+exec?

posix_spawn() provides a combined fork+exec operation designed to be efficient and safe, especially on systems without MMU (no virtual memory) or in multithreaded programs.

Prototype:

#include <spawn.h>
int posix_spawn(pid_t *pid, const char *path,
                const posix_spawn_file_actions_t *file_actions,
                const posix_spawnattr_t *attrp,
                char *const argv[], char *const envp[]);

Why posix_spawn over fork+exec:

Multithreaded safety: fork() in a multithreaded program is problematic (only one thread survives, mutexes may be locked). posix_spawn() avoids this.
MMU-less systems: No virtual memory means no COW, making fork() expensive or impossible. posix_spawn() can use vfork internally.
File actions: Declaratively specify I/O redirections (open, close, dup2) to perform between fork and exec.
Attributes: Set signal masks, process group, scheduling policy, etc.

posix_spawnp() is the variant that searches PATH (like execlp).

The API is more verbose but avoids the unsafe window between fork and exec where async-signal-safety rules apply.

Pseudo Code

1. Initialize file_actions (optional redirection)
2. Initialize attributes (optional signal/scheduling)
3. Call posix_spawn(&pid, path, &file_actions, &attrs, argv, envp)
4. On success: pid is set, new process is running
5. waitpid(pid, &status, 0) to reap

Equivalent to:
  fork()
  if child:
    apply file_actions (close/open/dup2)
    apply attributes (signal mask, pgid)
    exec(path, argv, envp)

Code

#include <spawn.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void) {
    pid_t pid;
    int status;

    /* Simple: run "ls -la /tmp" */
    char *argv[] = {"ls", "-la", "/tmp", NULL};
    extern char **environ;

    int ret = posix_spawnp(&pid, "ls", NULL, NULL, argv, environ);
    if (ret != 0) {
        fprintf(stderr, "posix_spawnp: %s\n", strerror(ret));
        return 1;
    }
    waitpid(pid, &status, 0);
    printf("ls exited with %d\n", WEXITSTATUS(status));

    /* With file actions: redirect stdout to a file */
    posix_spawn_file_actions_t actions;
    posix_spawn_file_actions_init(&actions);
    posix_spawn_file_actions_addopen(&actions, STDOUT_FILENO,
        "output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);

    char *argv2[] = {"echo", "hello from posix_spawn", NULL};
    ret = posix_spawnp(&pid, "echo", &actions, NULL, argv2, environ);
    posix_spawn_file_actions_destroy(&actions);

    if (ret == 0) {
        waitpid(pid, &status, 0);
        printf("echo wrote to output.txt\n");
    }

    return 0;
}

[ls -la /tmp output]
ls exited with 0
echo wrote to output.txt

Key Points

•posix_spawn combines fork+exec in one call
•Safer in multithreaded programs than fork()
•posix_spawnp searches PATH (like execlp)
•File actions specify I/O redirections declaratively
•Returns error code directly (not -1 + errno)

Gotchas

•posix_spawn returns the error code directly (not via errno) -- check ret != 0
•Not as flexible as fork+exec for complex setup between fork and exec
•File actions and attributes must be initialized and destroyed (memory management)
•Not all systems support all posix_spawnattr flags (e.g., POSIX_SPAWN_SETSID is recent)

posix_spawn()/posix_spawnp() combine fork+exec in one call. Safer in multithreaded programs and on MMU-less systems. Use file actions for I/O redirection. Returns error code directly (not -1 + errno).

•Combines fork+exec safely
•posix_spawnp searches PATH

#include <spawn.h>
#include <sys/wait.h>
#include <stdio.h>

int main(void) {
    pid_t pid;
    extern char **environ;
    char *argv[] = {"echo", "hello", NULL};
    int ret = posix_spawnp(&pid, "echo", NULL, NULL, argv, environ);
    if (ret == 0) {
        int st;
        waitpid(pid, &st, 0);
    }
    return 0;
}

Returns error code directly, not via errno

Built by onllm.dev

Home GitHub Support awesomePrep