Linux system errors
Termination Request
Reviewed for reference consistency: August 11, 2026
a polite shutdown signal the process may handle before exiting
What 143 Means
The 143 error on the Linux system errors indicates termination request — a polite shutdown signal the process may handle before exiting. This typically occurs due to an administrator or script running kill with its default signal.
Exit code 143 is the arithmetic for 128 + 15, SIGTERM: the standard shutdown request arrived and the process ended — gracefully when a handler got its cleanup window, or on the spot when none existed.
How to fix 143
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.
Send the polite request
Plain kill defaults to TERM, giving a handler-armed process its chance to shut down cleanly.
kill -TERM $(pidof your_process)Widen a container's grace window
The stop timeout controls how long the runtime waits between TERM and its kill escalation, giving slow shutdown handlers room.
docker stop -t 30 your_container
Technical Background
SIGTERM is the default request behind the plain kill command, and the entire shutdown etiquette of Unix systems rests on it. Supervisors send TERM first, wait a grace period, and only then consider KILL — the sequence assumes a well-behaved program will catch the signal, release its resources, and walk out the door on its own.
The catchability is the point. A database can checkpoint; a web server can drain connections; a build tool can leave a note about the interrupted step. Programs that install a TERM handler convert a termination into an orderly exit, and orchestrators time-box that civility with their grace periods — docker stop's default ten seconds being the familiar example.
Exit code 143 is the arithmetic's verdict, not a value judgment: 128 + 15 records the cause. A killed batch job and a gracefully drained server can surface the same code, which is why shutdown quality is judged by the logs around the exit rather than by the number alone.
Common Causes
- An administrator or script running kill with its default signal
- A process manager or service supervisor stopping a unit as part of shutdown or redeploy
- A container runtime ending the grace period before its final kill escalation
Typical Scenarios
- A systemctl stop or restart delivering TERM to a service whose handler then exits cleanly
- A docker stop giving a container its grace window; the app exits and the shell or orchestrator logs 143
- A long-running batch job killed by a scheduler's TERM during a maintenance window
What to Know
When a TERM arrives unexpectedly, the sender matters more than the receiver: supervisor logs and process-manager state identify the shutdown that triggered it. The gap between TERM and any later KILL defines how much cleanup the process could actually perform.
Frequently Asked Questions
Common questions about Linux 143 error
143 is SIGTERM (signal 15) — a request the process could acknowledge and handle. 137 is SIGKILL (signal 9) — an order with no handler possible. Seeing 143 means the program got its chance; 137 means it did not.
No. Handlers can delay or clean up, but every supervisor chain ends in SIGKILL: container runtimes after their grace period, process managers after their own timeout. TERM is the polite first move, not the last word.
The shell reports signal deaths as 128+N regardless of grace. A program that caught TERM, closed its files, and exited via its handler still often surfaces as 143 — the code marks the cause of death, not its civility.
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
Connection Hangup — the controlling terminal closed; daemons repurpose it as a config-reload trigger
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.