EC
129
BashWARNINGNotableSignalHIGH confidence

Hangup (SIGHUP)

Production Risk

Common in SSH sessions; use nohup, screen, or tmux for jobs that must survive logout.

What this means

Exit code 129 (128+1) indicates the process received SIGHUP — the hangup signal. Originally sent when the controlling terminal is closed; now commonly used by daemons as a signal to reload their configuration.

Why it happens
  1. 1The SSH session or terminal that started the process was closed
  2. 2A process manager sent SIGHUP to trigger a config reload
  3. 3The controlling terminal was disconnected
How to reproduce

A foreground process receives SIGHUP when the terminal closes.

trigger — this will error
trigger — this will error
# In another terminal: kill -HUP <PID>
# or close the terminal that started the process
# Process exits with code 129

expected output

Hangup
Exit: 129

Fix 1

Use nohup to survive terminal close

WHEN Running long jobs that should outlive the terminal

Use nohup to survive terminal close
nohup your_command &
# Or with disown:
your_command &
disown

Why this works

nohup makes the process ignore SIGHUP and redirects stdout/stderr to nohup.out. disown removes the job from the shell job table.

Fix 2

Trap SIGHUP for config reload in daemons

WHEN Writing a long-running service

Trap SIGHUP for config reload in daemons
#!/bin/bash
reload_config() {
  echo "Reloading config..." >&2
  source /etc/myservice/config.sh
}
trap reload_config HUP

while true; do
  do_work
done

Why this works

Trapping SIGHUP for config reload is the UNIX convention for daemons (e.g., nginx -s reload sends SIGHUP).

What not to do

✕ Run long jobs in SSH without nohup or tmux

The job will be killed when the SSH session closes, sending SIGHUP to all processes in the session.

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All Bash errors