Linux system errors
User Signal 1
Reviewed for reference consistency: August 11, 2026
an application-defined control channel rather than an error state
What 138 Means
The 138 error on the Linux system errors indicates user signal 1 — an application-defined control channel rather than an error state. This typically occurs due to an operator or script sending kill -usr1 as the application's documented control gesture.
Exit code 138 decodes to 128 + 10, a USR1 delivery. What that delivery meant depends on the target program's handler table: a log reopen for one daemon, a state dump for another, and a plain kill for a process that never registered a handler.
How to fix 138
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.
Invoke the handler deliberately
Sending USR1 to the intended daemon exercises its control path — log reopen, state dump, or whatever the application defined.
kill -USR1 $(pidof your_daemon)Watch signal deliveries live
Attaching a tracer with signal reporting shows who delivers what to the process, and how its handlers answer.
strace -e trace=signal -p $(pidof your_daemon)
Technical Background
Nothing in the kernel gives SIGUSR1 a job. It exists so applications can have a private doorbell, and what the doorbell does is written in the application, not the operating system. That makes 138 the rare exit code whose meaning you cannot decode from the number alone — the target program's handler list is the missing half.
The classic use is log rotation: the rotator renames a server's log file, then signals USR1 so the server reopens fresh descriptors instead of writing into a renamed file for the rest of its life. Profilers, load balancers, and in-house daemons each bolt their own conventions onto the same signal.
The failure mode is asymmetry. A sender assuming every daemon speaks USR1 will, sooner or later, signal one that never registered a handler — and the default disposition converts the control gesture into a plain kill.
Common Causes
- An operator or script sending kill -USR1 as the application's documented control gesture
- The application's own USR1 handler deciding to exit after flipping its internal state
- USR1 delivered to a process that never registered a handler, hitting the default kill
Typical Scenarios
- A log-rotation setup asking a server to reopen its files by signalling USR1
- A custom daemon using USR1 as a debug-mode toggle during a live incident
- A script firing kill -USR1 at the wrong target process, which has no handler and dies
What to Know
Decoding an unexpected 138 means identifying the sender and the target's handler set. A signal trace on the running process shows deliveries as they happen, separating deliberate control gestures from stray kills.
Frequently Asked Questions
Common questions about Linux 138 error
Only by accident. When the process registered a USR1 handler, the signal is a control action. Exit 138 appears when a handler chose to exit or when no handler existed — the default disposition kills the process.
Conventions differ per application: many servers reopen logs on USR1, some profiling tools dump state, and custom daemons define their own. The application's own materials are the only reliable reference for what its USR1 does.
129 (SIGHUP) carries the terminal-hangup history and the daemon reload convention. 138 (SIGUSR1) has no history at all — its meaning is whatever the target program decided, if it decided anything.
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 2 — the second application-defined channel, with a meaning set per program
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.