Linux system errors
Connection Hangup
Reviewed for reference consistency: August 11, 2026
the controlling terminal closed; daemons repurpose it as a config-reload trigger
What 129 Means
The 129 error on the Linux system errors indicates connection hangup — the controlling terminal closed; daemons repurpose it as a config-reload trigger. This typically occurs due to ssh or terminal session ending while a foreground job was still running.
Exit code 129 is 128 + 1, the shell's report that the process died from SIGHUP. The signal was born for physical line dropouts, but modern daemons flipped its meaning: for many servers SIGHUP is the conventional reload signal, so the same delivery can mean routine maintenance or the death of a terminal session.
How to fix 129
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Detach the job from the terminal's fate
Starting a long job under nohup makes it ignore SIGHUP, so the SSH session can close without killing the work.
nohup ./your_script.sh &Move a running job out of the session
After suspending a job with Ctrl+Z and resuming it in the background, disown removes it from the shell's SIGHUP broadcast list.
disown %1Send the conventional reload signal
For daemons that support SIGHUP reloads, this re-reads configuration without a restart. Processes without a handler will die instead, so the daemon's behavior matters first.
kill -HUP $(pidof your_daemon)
Technical Background
SIGHUP carries physical terminals inside its name: when a dial-up connection dropped, the kernel notified the session's processes that the line was gone. The transport disappeared, but the convention survived the hardware.
Two meanings now live on one signal. Interactive shells forward SIGHUP when the session ends, killing attached jobs. Long-lived daemons instead read SIGHUP as the traditional reload trigger — configuration files are re-read without stopping the process, which is why editors' worth of server documentation treats kill -HUP as routine maintenance.
A process with no SIGHUP handler dies by default, so the same delivery that reloads one service will silently terminate another.
Common Causes
- SSH or terminal session ending while a foreground job was still running
- A terminal emulator window or serial line closing under the session leader
- An explicit kill -HUP sent as a config-reload request to a daemon without a handler
Typical Scenarios
- Closing an SSH session while a long build or download runs in the foreground
- A datacenter operator sending kill -HUP to a nameserver to pick up edited zone files
- A tmux or screen session being killed outright, SIGHUP reaching every attached process
What to Know
Distinguishing terminal death from a reload attempt starts with knowing who sent the signal: the session ending, a process manager, or an operator's kill -HUP. Job-control settings decide whether an SSH disconnect should reach a job at all.
Frequently Asked Questions
Common questions about Linux 129 error
The terminal closing sends SIGHUP to the session's jobs. A job started with nohup or moved out of the job table with disown ignores that delivery and keeps running.
No. For daemons that treat SIGHUP as reload, a clean reload followed by exit can surface as 129. Context decides: a dead interactive job is a hangup, a restarted service may be a reload.
129 is SIGHUP (signal 1), 130 is SIGINT (signal 2). SIGINT comes from Ctrl+C in the same terminal; SIGHUP comes from the terminal's own death or an explicit kill -HUP.
Related Error Codes
Process Killed — the process was terminated by a SIGKILL signal
Terminated by User — the process was interrupted by a SIGINT signal
Invalid Exit Argument — script exited with an out-of-range status or terminated by a signal
Termination Request — a polite shutdown signal the process may handle before exiting
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
You have unresolved file conflicts preventing Git from completing the current operation.
You tried to add a remote named 'origin', but one with that name already exists.
Git does not know which remote branch should receive your pushed commits.
You checked out a specific commit, detaching your working directory from the branch history.