📘 Exit Status Code = 130 in Bash

---

---

🎯 What You Will Learn

1. Understand what exit status code = 130 means in Bash.
2. Learn how Bash interprets termination by signals (e.g., Ctrl+C, SIGINT).
3. Differentiate 130 from 1, 126, and 127.
4. Observe how long-running or background processes are interrupted.
5. Apply safe handling of exit code 130 in WordPress VPS automation (e.g., backups, updates, monitoring).
6. Learn how to prevent and handle user-terminated or signal-based interruptions in scripts.

---

1. 5W + 1H Framework

Element	Description
What	Exit code 130 means the process was terminated by the user or received a SIGINT signal — typically by pressing Ctrl+C.
Why	It indicates intentional interruption rather than an execution or syntax error.
Who	Bash users running long or continuous commands, cron tasks, or automation loops.
When	When a user sends a termination signal (SIGINT) or an external process stops your running command.
Where	In terminal sessions, background jobs, and WordPress VPS scripts involving long processes (e.g., backups, plugin updates).
How	Bash sets $? = 130 to indicate termination by signal 2 (SIGINT).

---

2. Prerequisites

You should already know:

• Exit status concepts (0 = success, non-zero = failure).
• How to view exit code with $?.
• How to run and stop commands in Bash (Ctrl+C, kill).
• Basics of process signals (SIGINT, SIGTERM).

---

3. Core Syntax and Examples

🧩 Definition

Exit code 130 = Process terminated by signal 2 (SIGINT), commonly caused by Ctrl+C.

Example 1 – User Interrupt (Ctrl+C)

sleep 10
# Press Ctrl+C before 10 seconds
echo $?

Expected Output:

^C
130

Explanation: sleep waits 10 seconds, but pressing Ctrl+C sends SIGINT (signal 2). Bash reports exit code 128 + 2 = 130. Use Case (WordPress VPS): When cancelling a long-running WP-CLI operation (e.g., wp search-replace).

Example 2 – Script Interrupted Manually

#!/bin/bash
echo "Starting task..."
sleep 30
echo "Task completed."

Run it:

bash test_interrupt.sh
# Press Ctrl+C mid-way
echo $?

Expected Output:

Starting task...
^C
130

Explanation: Script received SIGINT before completion — exit code 130 confirms it was user-terminated.

Example 3 – Process Killed Externally

sleep 60 &
kill -2 $!
wait $!
echo $?

Expected Output:

130

Explanation: kill -2 sends SIGINT (signal 2) to the background process. Bash returns exit code 130 because the termination signal was explicit. Use Case: Monitoring scripts that terminate long-running backup tasks gracefully.

Example 4 – Handling SIGINT Gracefully in Script

#!/bin/bash
trap "echo 'Process interrupted. Cleaning up...'; exit 130" SIGINT
echo "Running backup..."
sleep 20
echo "Backup completed."

Run:

bash safe_backup.sh
# Press Ctrl+C before completion

Expected Output:

Running backup...
^C
Process interrupted. Cleaning up...

Explanation: trap catches the SIGINT signal, allowing cleanup before exit. The script exits with 130 manually to preserve correct semantics. Use Case (WordPress VPS): Gracefully stopping an ongoing database export without corrupting the dump.

4. Common Scenarios Triggering Exit Code 130

Scenario	Example	Description
Manual termination	Ctrl+C	User sends SIGINT
Script killed	kill -2 PID	SIGINT sent programmatically
Docker container stopped	docker stop container	Sends SIGTERM/SIGINT internally
Cron job interrupted	Admin stops task	Manual stop via terminal
WP-CLI operation cancelled	wp db export aborted	User interruption or timeout
SSH session closed	exit during execution	Remote disconnect signal

---

5. WordPress VPS Use Cases

Use Case	Example	Explanation
Interrupted database backup	wp db export backup.sql	User pressed Ctrl+C before completion
Plugin update aborted	wp plugin update --all	Script stopped by operator
Long-running import stopped	wp import data.xml	User manually terminated
Cache rebuild stopped	wp cache flush && wp cache rebuild	SIGINT during process
Cron sync aborted	/root/wp-sync.sh stopped manually	Cron or SSH session interrupted

---

6. Troubleshooting Matrix

Symptom	Cause	Solution
Script exits with code 130	Manual Ctrl+C or SIGINT	Add trap for graceful cleanup
Background process stops	External kill signal	Review logs or use ps -ef
Repeated interruptions	User or automation conflict	Add retry or confirmation prompt
Cron job logs “exit 130”	Process timed out	Extend execution time or use timeout
WP-CLI task incomplete	User stopped process	Re-run safely or add checkpoint logic

---

7. Best Practices

1. Handle interruptions gracefully:

trap "echo 'Stopped safely. Exiting...'; exit 130" SIGINT

2. Avoid data corruption by saving partial progress before exiting.
3. Log interruption events:

echo "$(date): Script interrupted (exit 130)" >> /var/log/script.log

4. Automate retry logic after exit 130 for idempotent tasks:

./task.sh || [ $? -eq 130 ] && ./task.sh

5. Use trap for multiple signals (SIGINT, SIGTERM, SIGQUIT):

trap "cleanup; exit 130" SIGINT SIGTERM SIGQUIT

---

8. Quick Lab – Manual Termination

Step 1: Create a test script

nano /root/exit130_test.sh

Step 2: Insert code

#!/bin/bash
echo "Performing long task... (Press Ctrl+C to stop)"
sleep 20
echo "Completed successfully."

Step 3: Run it

bash /root/exit130_test.sh
# Press Ctrl+C midway
echo $?

Expected Output:

Performing long task... (Press Ctrl+C to stop)
^C
130

Explanation: The process was interrupted. Exit code confirms manual stop.

9. Cheat Sheet

Exit Code	Meaning	Description
0	Success	Command executed successfully
1	General error	Runtime or logical failure
2	Misuse of shell builtins	Syntax or structure error
126	Command cannot execute	Permission or binary issue
127	Command not found	Missing or invalid path
130	Terminated by SIGINT	User pressed Ctrl+C or signal sent

---

10. Mini-Quiz

1. What does exit code 130 represent?
2. Which key combination generates exit 130?
3. How can you trap SIGINT to run cleanup before exit?
4. What does 128 + 2 represent in Bash exit codes?
5. Why is it important to handle signal-based exits in WordPress backup scripts?

---

Would you like me to continue next with Exit Status Code = 137 (Killed by SIGKILL / Out-of-Memory) — which often happens in VPS or Docker environments when the kernel terminates a process automatically?