Linux system errors
Quit Signal
Reviewed for reference consistency: August 11, 2026
a Ctrl+\ interrupt that terminates the process and leaves a core dump
What 131 Means
The 131 error on the Linux system errors indicates quit signal — a ctrl+\ interrupt that terminates the process and leaves a core dump. This typically occurs due to ctrl+\ pressed in a terminal, delivering sigquit to the foreground process group.
Exit code 131 encodes 128 + 3: the process died from SIGQUIT, the signal Ctrl+\ sends, and by default the death leaves a core dump for post-mortem reading.
How to fix 131
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.
Check the core dump setting
Core sizes are capped by the shell's ulimit; a value of 0 disables dumps even when SIGQUIT fires.
ulimit -cList collected cores on systemd systems
systemd-coredump stores and indexes dumps from QUIT deaths, ready for inspection without manual file hunting.
coredumpctl listOpen the dump in a debugger
Loading the core beside its binary shows the stack that QUIT froze in time.
gdb ./your_program /path/to/core
Technical Background
Ctrl+\ behaves like Ctrl+C with a different contract. SIGINT asks a program to stop and expects it to clean up; SIGQUIT is what a user presses when the polite route already failed, and the kernel's default handler pays for that impatience with a core image of the dying process.
The signal also has a second life inside runtimes. Java applications turn QUIT into a thread dump printer, so operators probe a healthy JVM's internals with the same key combination that executes a misbehaving C program. One signal, opposite outcomes — handler or no handler.
Shell scripts report the death as 131 through the same 128+N arithmetic as every fatal signal.
Common Causes
- Ctrl+\ pressed in a terminal, delivering SIGQUIT to the foreground process group
- A language runtime mapping QUIT to a diagnostic dump, as the JVM does for thread dumps
- A process manager sending SIGQUIT to force a faster exit than SIGTERM allows
Typical Scenarios
- Escaping a terminal program that ignored repeated Ctrl+C attempts
- Requesting a JVM thread dump on a console-attached Java process without killing it outright
- A supervisor escalating from SIGTERM to SIGQUIT when a worker misses its shutdown window
What to Know
A core dump from a QUIT death is the starting evidence: its location follows core_pattern or systemd-coredump. Whether the process died or merely reported depends on whether a handler intercepted the signal.
Frequently Asked Questions
Common questions about Linux 131 error
Systemd-based systems route cores through systemd-coredump, listable with coredumpctl. Elsewhere the kernel honors /proc/sys/kernel/core_pattern, which names the path and format of the dump.
130 records SIGINT from Ctrl+C; 131 records SIGQUIT from Ctrl+\. The quit variant is designed for diagnosis — it abandons graceful cleanup and leaves a core dump behind.
Yes. The JVM famously catches it to print thread dumps instead of dying, which is why a QUIT to a Java process often produces a diagnostic file rather than an exit at all.
Related Error Codes
Process Killed — the process was terminated by a SIGKILL signal
Exit Code 139 — process terminated by segmentation fault (Signal 11 / SIGSEGV)
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
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git paused the merge because it cannot automatically resolve overlapping changes.
Git aborted the merge to protect uncommitted changes in your working directory.
Git prevented a branch switch because it would overwrite unsaved changes in your working directory.
Git aborted the merge because it would overwrite untracked files in your working directory.