How to fix /bin/sh: can’t access tty; job control turned off in a minimal Linux OS (serial console)

by

Summary

A minimal Linux system booting to a BusyBox shell on a serial console (ttyS0) correctly executes commands but fails to provide job control, displaying the error /bin/sh: can't access tty; job control turned off. The root cause is that while the kernel console is directed to the serial device, the shell process itself is not assigned a Controlling Terminal. In this specific QEMU -nographic environment, the standard input (stdin) is not a TTY device, preventing the shell from establishing the necessary session leadership and terminal group ownership required for signals like SIGTSTP (Ctrl+Z) to function correctly.

Root Cause

The error is generated by the BusyBox shell (ash) when it attempts to perform TTY operations on file descriptor 0 (stdin). The failure stems from two compounding factors:

  • Non-TTY Standard Input: When using QEMU with -nographic and piping the output to a serial console, the standard input stream provided to the shell is often a pipe or a non-terminal file descriptor.
  • Missing setsid / ctty Attachment: The shell requires a process group and a controlling terminal to manage job control. Without explicitly attaching the shell to the TTY device (/dev/ttyS0), the shell cannot set up the required session semantics.
  • Missing Device Node: Even if the code logic were correct, a minimal initramfs often lacks the device node /dev/ttyS0, preventing any TTY operations.

Why This Happens in Real Systems

In production embedded systems, this scenario is common during the bring-up phase or when debugging via a serial interface. Developers often assume that routing the kernel printk messages to a serial port (console=ttyS0) automatically grants user-space processes access to that port as a controlling terminal.

However, user-space initialization is distinct from kernel console configuration. If the init process simply executes exec /bin/sh without ensuring stdin/stdout/stderr are connected to a TTY, the shell runs “headless.” This is further exacerbated in CI/CD pipelines or automated testing environments where the serial console is piped via FIFOs, strictly removing TTY characteristics from the IO streams.

Real-World Impact

  • Loss of Interactive Debugging: The inability to use Ctrl+Z, fg, and bg makes it difficult to pause runaway processes or switch between background tasks during system diagnostics.
  • Script Execution Errors: Shell scripts relying on job control or TTY interrogation (e.g., read -p) will fail or hang unexpectedly.
  • Signal Handling Failures: Ctrl+C (SIGINT) may fail to propagate correctly to child processes without a proper TTY setup.
  • Log Noise: The repeated error message /bin/sh: can't access tty clutters the console logs, making it difficult to spot actual runtime errors.

Example or Code

#!/bin/sh

# Mount essential filesystems
mount -t proc none /proc
mount -t sysfs none /sys

# Create necessary device nodes if devtmpfs is not used or incomplete
# mknod is optional if devtmpfs is mounted, but good practice for minimal setups
mkdir -p /dev
[ -c /dev/console ] || mknod /dev/console c 5 1
[ -c /dev/ttyS0 ] || mknod /dev/ttyS0 c 4 64

# Establish the TTY environment for the shell
# - 'exec' replaces the init process, so PID 1 becomes the shell
# - 'setsid' creates a new session and makes it the session leader
# - '--login' (or -l) forces the shell to attempt to open the controlling TTY
exec setsid /bin/sh --login  /dev/ttyS0 2>&1

How Senior Engineers Fix It

Senior engineers recognize that the kernel console is separate from the user-space controlling terminal. The fix involves bridging this gap explicitly in the init script:

  1. Ensure Device Presence: Explicitly verify or create the /dev/ttyS0 node using mknod.
  2. Utilize setsid: Use the setsid command to execute the shell. This forces the shell to become the session leader of a new session, which is a prerequisite for acquiring a controlling terminal.
  3. Redirection and Input Source: Explicitly redirect stdin, stdout, and stderr to /dev/ttyS0. Crucially, the shell must be started with --login (or -l) to trigger the logic where it opens the TTY as its controlling terminal.
  4. Verify Kernel Config: Ensure the kernel was built with CONFIG_SERIAL_8250 and CONFIG_SERIAL_8250_CONSOLE enabled, which the user has already confirmed.

Why Juniors Miss It

Junior engineers often rely on high-level distributions (like Ubuntu or Debian) where getty or systemd-logind handles these complexities transparently. They misunderstand the relationship between the Kernel Console (where messages go) and the Controlling Terminal (where signals come from). They assume that because they see a shell prompt, the shell is fully interactive. They often try to fix the shell command (e.g., busybox sh) rather than the environment in which the shell is launched (setsid and redirection), missing the concept of session leadership and process groups.