Linux system errors
User Signal 2
Reviewed for reference consistency: August 11, 2026
the second application-defined channel, with a meaning set per program
What 140 Means
The 140 error on the Linux system errors indicates user signal 2 — the second application-defined channel, with a meaning set per program. This typically occurs due to a control script or operator sending kill -usr2 to trigger the application's second defined action.
Exit code 140 resolves to 128 + 12, the second user channel. USR2 has no built-in meaning; the target's handler — or lack of one — decides the outcome.
How to fix 140
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.
Trigger the program's defined action
For processes that register a USR2 handler, this exercises the second control path — an upgrade, rotation, or state change the application chose.
kill -USR2 $(pidof your_daemon)Review the service's recent behavior
For services under a process manager, the unit journal records what the handler did after the delivery.
journalctl -u your_service -n 50
Technical Background
USR2 shares nothing with USR1 except being free. Both signals are unassigned by the kernel, and everything they do lives in application code. Exit code 140 therefore decodes as 'a USR2 was delivered and the process ended' — whether that end was a planned transition or a default-disposition kill depends entirely on the target.
The best-known USR2 role is the live binary upgrade: certain server families use it to start a fresh executable and hand existing connections over without dropping them. That sophistication makes the signal look meaningful in general, but the upgrade dance is one application's choice, not a platform contract.
Operations teams juggling both USR signals eventually feel the sharp edge: two daemons on one host, both reachable by the same control script, with handler sets that do not agree. The same keystroke reloads one and kills the other.
Common Causes
- A control script or operator sending kill -USR2 to trigger the application's second defined action
- An application's own USR2 handler performing an upgrade or state transition and exiting
- USR2 reaching a process without a handler, where the default disposition terminates it
Typical Scenarios
- A zero-downtime upgrade flow signalling a live server with USR2 to swap its executable in place
- An operator's control script using USR2 as a second, independent toggle beside USR1
- A stray USR2 from a copy-pasted control command landing on a process that has no handler
What to Know
As with USR1, the meaning of a delivery is defined by the target's handler table, and the sender's identity closes the loop. Live signal tracing remains the direct way to watch deliveries and handler responses on a running process.
Frequently Asked Questions
Common questions about Linux 140 error
Nothing is built in — both are empty channels. The difference is whatever the application assigned: one program might reopen logs on USR1 and upgrade itself on USR2, while another ignores both. Exit 140 records a USR2 delivery; exit 138 a USR1 delivery.
Most likely the target had no USR2 handler, so the kernel's default kill applied. The signal number in the exit code identifies the delivery, not the intent of the sender.
Only by coincidence of their own design. Conventions are per-program; the well-known upgrade-on-USR2 pattern of one server family has no force on any other binary.
Related Error Codes
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
User Signal 1 — an application-defined control channel rather than an error state
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.