Technical Analysis and Implementation of Infinite Blocking in Bash

Technical Background and Problem Scenario

In Linux desktop environments, users often start the X Window System using startx, which executes the .xinitrc configuration file. When a window manager (such as /usr/bin/mywm) is launched from .xinitrc, terminating the window manager process causes the X server to exit as the script reaches its end-of-file. To prevent this, developers need to implement blocking mechanisms at the script's end to keep the X server running.

Basic Solution: Looped Sleep

The most straightforward approach is adding an infinite loop at the end of .xinitrc:

while true; do sleep 10000; done

This method achieves approximate blocking through repeated sleep command execution, but has significant drawbacks: it's essentially periodic wake-ups rather than true blocking, consumes minimal CPU resources, and the sleep command typically has maximum duration limits (usually 24 days on Linux systems).

Core Solution: The sleep infinity Command

According to the best answer, sleep infinity is the recommended method for infinite blocking. The command's behavior depends on implementation:

• On some systems, it truly sleeps indefinitely
• On others, it sleeps for the maximum allowed duration (e.g., 24 days) before automatically waking

Using strace sleep infinity reveals the actual system calls:

$ strace sleep infinity
execve("/bin/sleep", ["sleep", "infinity"], 0x7ffd78b0b8d0 /* 58 vars */) = 0
nanosleep({tv_sec=86400, tv_nsec=0}, NULL) = 0
nanosleep({tv_sec=86400, tv_nsec=0}, NULL) = 0
...

The trace shows that even with the infinity argument, sleep may internally loop nanosleep system calls, each sleeping for 24 hours (86400 seconds). This indicates it's not completely blocking but rather looping at an extremely low frequency.

Alternative Approaches: Deep Analysis

The Misconception of tail -f /dev/null

Some online suggestions propose tail -f /dev/null for blocking, but this is actually incorrect. Analysis with strace:

$ strace tail -f /dev/null
inotify_add_watch(3, "/dev/null", IN_MODIFY) = 1
read(0, "", 4096) = 0
...

This command continuously monitors /dev/null for changes using inotify system resources and wakes when other processes write to /dev/null. On busy systems, this can generate dozens of system calls per second, consuming far more resources than sleep approaches.

Fifo-Based Blocking Techniques

Using named or anonymous fifos enables true blocking since the read command waits indefinitely when no input is available. Two implementation methods:

Anonymous fifo (Bash 4+):

bash -c 'coproc { exec >&-; read; }; eval exec "${COPROC[0]}<&-"; wait'

This creates a coprocess, closes all output file descriptors, executes blocking read, then waits for the coprocess completion via wait. This method requires keeping two PIDs and a fifo open.

Named fifo:

mkfifo "$HOME/.pause.fifo" 2>/dev/null; read <"$HOME/.pause.fifo"

After creating a named pipe, read blocks until data becomes available. Blocking can be terminated by writing data to the pipe via touch "$HOME/.pause.fifo". This approach is simpler but requires filesystem entity management.

Direct System Call Access

The Linux kernel provides the pause() system call, which suspends a process indefinitely until a signal is received. While no direct userspace command exists, it can be implemented programmatically:

C implementation:

#include <unistd.h>
int main() {
    for(;;) pause();
    return 0;
}

Compilation produces a minimal executable that truly implements infinite blocking.

Python implementation:

python -c 'while 1: import ctypes; ctypes.CDLL(None).pause()'

Using the ctypes library to directly call the C library's pause() function, slightly less efficient but requires no compilation.

Technical Comparison and Selection Guidelines

For most application scenarios, sleep infinity or looped sleep approaches are recommended. They offer optimal portability and ease of use, and while not completely blocking, their practical effectiveness suffices for requirements. Only in special cases requiring absolute blocking and accepting system dependencies should fifo or system call approaches be considered.

Practical Implementation Examples

Complete example for keeping X server running in .xinitrc:

#!/bin/bash
# Start window manager
exec /usr/bin/mywm

# Method 1: Using sleep infinity (recommended)
sleep infinity

# Method 2: Optimized looped sleep (better compatibility)
while :; do
    sleep 2073600  # 24 days
    # Or use maximum safe value
    # sleep $((2**31-1))
done

# Method 3: Named fifo approach (true blocking)
PAUSE_FIFO="$HOME/.xinit_pause"
[ -p "$PAUSE_FIFO" ] || mkfifo "$PAUSE_FIFO"
read <"$PAUSE_FIFO"

Signal Handling Considerations

All blocking methods can be interrupted by signals. Production scripts should include signal handling:

#!/bin/bash
trap 'echo "Received signal, exiting"; exit' INT TERM

# Main program
exec /usr/bin/mywm

# Blocking section
while :; do
    sleep 3600
    # Check if window manager is still running
    if ! pgrep -x "mywm" >/dev/null; then
        echo "Window manager terminated, exiting"
        exit 1
    fi
done

By adding signal trapping and state checking, more robust scripts can be created that properly clean up and terminate X sessions when window managers exit abnormally.