DEV Community: Anguishe

Your Server Is at 97% CPU Right Now. Would You Know?

Anguishe — Fri, 22 May 2026 11:00:00 +0000

Here's how it usually goes:

You deploy something. Traffic is light. Server load sits at 15% and you move on to the next thing. Then traffic grows, or a cron job stacks on itself, or a memory leak slowly eats through your RAM over 72 hours. By the time you notice, the server is thrashing, responses take 8 seconds, and your app is effectively dead.

The frustrating part is that the tools to catch this have been on your server the entire time. top and free ship with every Linux distribution ever made. Nobody installs them. They're just... there. Waiting for someone to actually ask.

So I wrote a script that asks every hour and logs a warning when the answer is bad.

The Script

#!/bin/bash

CHECK="✓"
CROSS="✗"

# --- Configuration ---
THRESHOLD=80                    # Alert when usage exceeds this %
LOG_FILE="/var/log/resource-monitor.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# --- CPU Usage ---
CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d',' -f1 | xargs printf "%.0f")

# --- RAM Usage ---
RAM=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')

echo "[$DATE] CPU: ${CPU}% | RAM: ${RAM}%"

# --- CPU Alert ---
if [ "$CPU" -gt "$THRESHOLD" ]; then
  echo "$CROSS [$DATE] WARNING: CPU at ${CPU}% (threshold: ${THRESHOLD}%)" | tee -a "$LOG_FILE"
else
  echo "$CHECK CPU OK: ${CPU}%"
fi

# --- RAM Alert ---
if [ "$RAM" -gt "$THRESHOLD" ]; then
  echo "$CROSS [$DATE] WARNING: RAM at ${RAM}% (threshold: ${THRESHOLD}%)" | tee -a "$LOG_FILE"
else
  echo "$CHECK RAM OK: ${RAM}%"
fi

Runs in under a second. Zero dependencies. Works on Ubuntu, Debian, CentOS, RHEL, Arch — anything with top and free, which is everything.

How the CPU Check Actually Works

The CPU line looks intimidating, so let me walk through it:

top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d',' -f1 | xargs printf "%.0f"

top -bn1 — runs top in batch mode (-b) for exactly one iteration (-n1). Batch mode dumps the full output to stdout instead of opening the interactive TUI. This is the only way to use top in a script.

grep "Cpu(s)" — grabs the line that shows aggregate CPU stats.

awk '{print $2}' — pulls the user CPU percentage (the second field).

cut and xargs printf — strips the percent sign and any comma decimal separator, then rounds to an integer. You can't do integer comparison in bash with 2.5 — it needs a clean number like 3.

The RAM check is simpler: free shows total and used memory, and awk divides used by total and multiplies by 100.

The Thing About `tee -a`

You'll notice the script uses echo ... | tee -a "$LOG_FILE" for warnings but plain echo for healthy checks. This is intentional.

tee -a writes to the terminal AND appends to the log file simultaneously. When everything is fine, there's nothing to log — you don't want a log file full of "CPU OK" lines every hour for three years. You only want entries when something is actually wrong. So the log file becomes a clean history of every resource spike your server has had, with timestamps.

When something breaks at 2 AM and you're debugging at 9 AM, you can cat /var/log/resource-monitor.log and see exactly when resources started climbing.

Schedule It

crontab -e

Hourly checks (what I use for most servers):

0 * * * * /home/user/monitor.sh >> /var/log/monitor-cron.log 2>&1

Every 5 minutes (for production servers where you need tighter visibility):

*/5 * * * * /home/user/monitor.sh >> /var/log/monitor-cron.log 2>&1

Not sure about the cron syntax? I have a cron job builder tool that generates the line visually.

Variations That Are Worth Adding

Add an email alert when thresholds are breached:

if [ "$CPU" -gt "$THRESHOLD" ]; then
  MSG="$CROSS WARNING: CPU at ${CPU}% on $(hostname) at $DATE"
  echo "$MSG" | tee -a "$LOG_FILE"
  echo "$MSG" | mail -s "[ALERT] High CPU on $(hostname)" you@example.com
fi

I have a full email alert script that covers the mail setup if you haven't configured it before.

Check disk space in the same script:

DISK=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$DISK" -gt "$THRESHOLD" ]; then
  echo "$CROSS [$DATE] WARNING: Disk at ${DISK}%" | tee -a "$LOG_FILE"
fi

Now you've got CPU, RAM, and disk in one pass. I keep disk in a separate script because I use a different threshold for it (90% vs 80%), but combining them works fine if you want fewer cron entries.

Log to a CSV for trending:

echo "$DATE,$CPU,$RAM" >> /var/log/resource-history.csv

Run this for a week and you'll see patterns. Maybe your app spikes every day at 2 PM when a batch job runs. Maybe RAM creeps up 1% per day, which means you have a memory leak that'll hit the wall in three months. You can't see these patterns without historical data.

When This Isn't Enough

This script is a notification system, not a monitoring platform. It tells you "something is wrong right now" but doesn't give you graphs, dashboards, or historical trending out of the box.

If you need that level of visibility, tools like Netdata (free, runs locally) or Grafana + Prometheus are the next step. But for a single VPS or a handful of servers, a cron script that logs warnings and optionally emails you is 90% of what you need — and it takes 2 minutes to deploy instead of 2 hours.

Full script, line-by-line breakdown, cron setup, and more variations:

bashsnippets.xyz/snippets/monitor-cpu-ram-usage.html

My Nginx Died at 2 AM and Nobody Noticed for 6 Hours. Now I Have a Watchdog Script.

Anguishe — Thu, 21 May 2026 11:00:00 +0000

Nginx crashed on a Saturday night. An OOM kill, probably — I was running a Node app that leaked memory like a broken faucet. The service went down at 2:14 AM. I found out at 8:30 AM when I opened my laptop and saw Slack messages from six hours earlier asking why the site was down.

The fix took 10 seconds: sudo systemctl start nginx. The downtime cost me a weekend of credibility.

The thing is, systemctl already knows when a service dies. I just wasn't asking it to check. So I wrote a script that asks every 60 seconds and restarts the service if it's down. Took less time to write than it did to explain the outage to my team.

The Script

#!/bin/bash

CHECK="✓"
CROSS="✗"

# --- Configuration ---
SERVICE="nginx"                              # Change to your service name
LOG_FILE="/var/log/service-watchdog.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
NOTIFY_EMAIL=""                              # Optional: you@example.com

# --- Check if service is running ---
if systemctl is-active --quiet "$SERVICE"; then
  echo "$CHECK [$DATE] $SERVICE is running"
else
  echo "$CROSS [$DATE] $SERVICE is NOT running — attempting restart..."
  echo "$CROSS [$DATE] $SERVICE DOWN — restarting" >> "$LOG_FILE"

  # --- Attempt restart ---
  if sudo systemctl start "$SERVICE"; then
    echo "$CHECK [$DATE] $SERVICE restarted successfully" | tee -a "$LOG_FILE"

    # --- Optional: send email notification ---
    if [ -n "$NOTIFY_EMAIL" ]; then
      echo "$SERVICE was down and has been restarted on $(hostname) at $DATE" \
        | mail -s "[RECOVERED] $SERVICE restarted" "$NOTIFY_EMAIL"
    fi
  else
    echo "$CROSS [$DATE] $SERVICE FAILED to restart — manual intervention needed" \
      | tee -a "$LOG_FILE"

    if [ -n "$NOTIFY_EMAIL" ]; then
      echo "$SERVICE failed to restart on $(hostname) at $DATE. Check: journalctl -u $SERVICE" \
        | mail -s "[CRITICAL] $SERVICE restart failed" "$NOTIFY_EMAIL"
    fi
  fi
fi

Why `systemctl is-active --quiet` and Not Something Else

I've seen people use ps aux | grep nginx for this. Don't. Here's why:

ps aux | grep nginx has a classic gotcha — the grep command itself shows up in the results because the word "nginx" is in the grep command line. People "fix" this with grep -v grep which works but is fragile and ugly. You're parsing process tables to answer a question that systemd already tracks natively.

systemctl is-active --quiet "$SERVICE" asks systemd directly: "is this unit in the active state?" The --quiet flag suppresses output and just returns an exit code. 0 means active. Anything else means it's not running. Clean, reliable, no string parsing.

The Two-Level Failure Check

This isn't just "is it down → restart it." There are two separate failure modes:

Level 1: Is the service running? If yes, print the check mark and exit. No log noise, no wasted disk.

Level 2: If the service is down and we try to restart it — did the restart actually work? systemctl start can fail for a dozen reasons: masked unit, broken config file, dependency that's also down, port already in use by something else. The script checks the exit code of the start command and sends a different email depending on whether recovery succeeded or failed.

The [RECOVERED] email means the script fixed it and you can keep sleeping. The [CRITICAL] email means something is actually broken and you need to look at it. That distinction matters at 3 AM.

Setting It Up with Cron

crontab -e

Add this line:

* * * * * /home/user/service-watchdog.sh >> /var/log/watchdog-cron.log 2>&1

That runs every single minute. Is that overkill? Maybe. But the script finishes in under 100ms when the service is healthy, and the alternative is 6 hours of downtime on a Saturday night. I'll take the overkill.

One gotcha with cron and sudo: cron runs with a minimal environment and no terminal. If sudo systemctl start prompts for a password, it hangs silently forever. You need a sudoers rule:

sudo visudo
# Add this line:
youruser ALL=(ALL) NOPASSWD: /bin/systemctl start nginx

Or just run the watchdog cron as root.

What Else I Watch With This

The SERVICE variable takes any systemd unit name. I run separate copies for:

nginx — the web server
mysql or mariadb — the database
docker — the container daemon
Custom services: my-node-app.service, redis-server, postgresql

If you want to watch multiple services in one script, loop through them:

SERVICES=("nginx" "mysql" "redis-server")
for SERVICE in "${SERVICES[@]}"; do
  # ... same check logic ...
done

But I prefer separate scripts per service because the logs stay clean and each one can have a different notification strategy.

Pairing This With Other Scripts

This watchdog handles the restart. But if you also want to know why the service died, pair it with:

Monitor CPU & RAM Usage — catches the OOM conditions that kill services in the first place
Send Email Alert from Bash — the email sending setup if you've never configured mail on Linux

Between these three scripts, you've got a basic monitoring stack that runs entirely on cron and costs nothing.

Full script, the line-by-line breakdown, cron setup walkthrough, and three more variations:

bashsnippets.xyz/snippets/restart-service-if-stopped.html

If you're managing any Linux server with services that need to stay up, this takes 5 minutes to deploy and runs quietly forever.

I Built a Free Tools Directory for Linux Users Who Are Tired of Googling the Same Commands

Anguishe — Wed, 20 May 2026 23:01:15 +0000

I Google "bash remove file extension" at least once a month.

Every time I need ${filename%.txt} I have to look it up. I've written that exact syntax probably 40 times across different scripts. My brain refuses to memorize it. And every time I need it again, I open a browser tab, type the question, scroll past three blog posts with 800-word intros about "the power of parameter expansion," and finally find the one-liner I need.

It takes 90 seconds. It shouldn't.

So I started building tools that solve problems at the exact moment I'm annoyed enough to fix them.

The Problem with Most Bash Resources

When you're debugging a script that's failing right now, you don't want a tutorial. You don't want to "learn the fundamentals." You want the answer in the next 30 seconds or you're going to lose your mind.

Most bash resources are written for people who have time. They assume you're sitting down with a cup of coffee to learn bash scripting as a general topic. They start with "What is bash?" and work up from there.

But that's not how real work happens.

Real work is: your cron job didn't run and you have no idea why. Your script is exiting with code 127 and you don't know what that means. You need to make a file executable for the owner but not readable by others and you can't remember if that's chmod 700 or chmod 600 or something else entirely.

You're not browsing for education. You're troubleshooting something that's on fire right now.

The Tools I Wish Had Existed

Here's what I've built so far, and more importantly, why each one exists:

1. Bash $PATH Debugger

The problem: I wasted 2 hours on a "command not found" error that made absolutely no sense.

I had a cron job that ran rsync to back up a directory. The script worked perfectly when I ran it manually. It failed silently when cron executed it. I checked the shebang. I checked permissions. I added logging. I even ran the script as the cron user manually — still worked.

Turns out cron runs with a minimal PATH that doesn't include /usr/local/bin, where my Homebrew-installed rsync lived. The script worked in my terminal because my shell's PATH included it. It failed in cron because cron's PATH didn't.

I spent those 2 hours Googling variations of "bash script works manually fails in cron" before I finally found a StackOverflow post explaining PATH inheritance in cron environments.

After I fixed it, I thought: "This is going to bite me again in 6 months when I've forgotten the lesson."

So I built the PATH debugger. You paste your $PATH, and it shows you:

Which directories actually exist on your system
Which are missing or broken
A cleaned export PATH=... line you can copy
Why common commands might fail (rsync not in any directory, python shadowed by a version in the wrong spot, etc.)

Now when someone tells me their script works manually but not in cron, I send them the tool. Problem identified in 30 seconds instead of 2 hours.

2. Cron Job Builder

The problem: I got cron syntax wrong three times in one week and broke production backups.

First attempt: * 2 * * * (which runs every minute during the 2am hour, not once at 2am).

Second attempt: Forgot to make the script executable, so cron failed silently.

Third attempt: The script ran but wrote to the wrong path because I didn't know cron doesn't expand ~.

After the third time I had to SSH into the server at 6am to figure out why backups hadn't run, I built the cron builder.

You pick the schedule visually (daily at 3am, every 6 hours, first Monday of the month, whatever), and it gives you:

The exact cron expression
The next 10 run times so you can verify it's actually what you want
A production-safe wrapper that includes logging, lock files, and absolute paths
A checklist of things that break (executable bit, PATH, environment variables)

Now I don't play cron roulette. I use the tool, copy the output, paste it into crontab -e, and it works the first time.

3. chmod Permissions Builder

The problem: I cannot hold octal permissions in my head.

Every single time I need to set file permissions, I have to look up whether 700 is owner-only or if that's 600, and whether 644 is the one where others can read or if I'm thinking of 755.

I've been using Linux for years. This should be automatic by now. It's not.

So I built a checkbox interface. You click read/write/execute for owner/group/others, and it shows you:

The octal number (chmod 755 script.sh)
The symbolic syntax (chmod u=rwx,g=rx,o=rx script.sh)
What those permissions actually mean in plain English

I've used this tool probably 30+ times since I built it. It's bookmarked on my work machine. I am not embarrassed about this.

4. Bash Exit Code Lookup

The problem: Your script exits with code 127, and you have no idea what that means.

Exit codes are one of those things where everyone knows 0 means success and 1 means generic failure, but beyond that it's trivia. What's 126? What's 130? What's the difference between 1 and 2?

The tool shows you:

What the code means (127 = command not found, 126 = permission denied, 130 = terminated by Ctrl+C)
Common causes
Copy-paste error handlers in three styles: if/else, case, and inline ||

Now when a script fails with a cryptic exit code, you don't have to Google "bash exit code 127" and scroll through five blog posts. You paste the number, get the answer, copy the error handler, move on.

5. Bash Boilerplate Generator

The problem: Every script starts with the same 15 lines, and I'm tired of typing them.

Shebang. set -euo pipefail. CHECK and CROSS variables. A header comment explaining what the script does. Sometimes argument parsing. Sometimes a trap handler for cleanup.

I was copy-pasting from an old script, deleting the parts I didn't need, and modifying what was left. That's fine for one script. It's tedious when you're writing scripts regularly.

So I built a generator. You pick what you need (strict error handling, argument parsing, logging, cleanup trap), optionally inject a snippet from the library (disk space check, file backup, whatever), and it gives you a complete .sh file ready to edit.

No blank file. No "where do I even start." Just a working script skeleton you can build on top of.

What's Coming Next

I'm not building "every bash tool imaginable." I'm building the ones I keep needing.

Next up:

Shellcheck Error Decoder — I'm tired of seeing SC2086 in my terminal and having to open a browser tab to figure out what the hell it means. Every modern bash tutorial tells you to run shellcheck. Every CI pipeline includes it. But the error codes are cryptic. This tool will decode them on the spot.

Bash String Manipulation Builder — The ${filename%.txt} problem I mentioned at the start. Parameter expansion is powerful and completely impossible to remember. Click what you want (remove extension, extract directory, lowercase the string), get the syntax.

Process Signal Reference — I have a note in my phone that says "SIGTERM = 15, SIGKILL = 9, SIGHUP = 1" because I can never remember which is which when a process won't die. Time to build the thing.

Maybe eventually if traffic justifies:

Bash Array Builder (because array syntax is different from literally every other language)
Redirect & Pipe Visualizer (I still think for 3 seconds every time I see 2>&1)

The Philosophy

These tools exist at the exact moment of maximum frustration.

You're not browsing the site for fun. You're here because something is broken right now and you need a fix right now.

That's the filter: If the tool solves a problem that's currently on fire, I build it. If it's "nice to know" or "general education," it doesn't make the cut.

I'm not trying to teach you bash. I'm trying to save you the 90 seconds you'd spend Googling the same thing you've Googled six times before.

Why I'm Building This in Public

I could keep these tools to myself. They're mostly for me anyway — shortcuts to problems I keep running into.

But I remember being the person who spent 2 hours on a PATH issue that should've taken 2 minutes. I remember breaking production cron jobs because the syntax is impossible to remember. I remember the feeling of Googling the same bash question for the third time this month and wondering if I'm just bad at this.

You're not bad at this. Bash syntax is inconsistent and hard to memorize, and the official documentation is written for people who already know what they're looking for.

If these tools save someone else those 2 hours or that feeling, that's worth making them public.

All tools are free, no signup, no limits:

bashsnippets.xyz/tools

And if you need actual scripts — monitoring, backups, automation, error handling — all the snippet pages are here:

bashsnippets.xyz/snippets

If you've built tools to solve your own repetitive problems, or if you have a bash thing you Google every month like I do, drop a comment. I'm curious what other people keep having to look up.

I Lost a Client's Database on a $5 VPS. Here's the 12-Line Script That Would Have Saved It.

Anguishe — Wed, 20 May 2026 17:56:29 +0000

It was a WordPress site on a $5 DigitalOcean droplet. Client's small business. Nothing fancy.

I had SSH access. I had root. I had every tool I needed to set up automated backups. I just... didn't. Because it was a small site. Because I'd "get to it later." Because the database was only 40MB and what could go wrong?

What went wrong was a botched plugin update that corrupted the wp_options table. No backup. No snapshot. No dump. Just a client on the phone asking why their site shows a white screen and me trying to explain that their content might be gone.

I rebuilt it from a cached Google version and a Wayback Machine scrape. Took two days. Billed zero.

That was the last time I ran a database without automated backups.

The Script

This is what I use now. Every server, every database, no exceptions.

#!/bin/bash

CHECK="✓"
CROSS="✗"

# --- Configuration ---
DB_USER="root"
DB_PASS="your_password"          # Or use ~/.my.cnf for security
DB_NAME="your_database"          # Change to your DB name
BACKUP_DIR="/var/backups/mysql"
KEEP_DAYS=7                       # Delete backups older than this
DATE=$(date '+%Y-%m-%d_%H-%M-%S')
FILENAME="${DB_NAME}_${DATE}.sql.gz"

# --- Create backup directory if it doesn't exist ---
mkdir -p "$BACKUP_DIR"

# --- Run the backup ---
echo "Backing up database: $DB_NAME..."

if mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "${BACKUP_DIR}/${FILENAME}"; then
  echo "$CHECK Backup created: ${BACKUP_DIR}/${FILENAME}"
  echo "$CHECK Size: $(du -sh "${BACKUP_DIR}/${FILENAME}" | cut -f1)"
else
  echo "$CROSS Backup FAILED for $DB_NAME — check credentials and database name"
  exit 1
fi

# --- Delete old backups ---
echo "Removing backups older than $KEEP_DAYS days..."
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +"$KEEP_DAYS" -delete
echo "$CHECK Cleanup complete"

# --- Show current backups ---
echo "Current backups:"
ls -lh "$BACKUP_DIR"/*.sql.gz 2>/dev/null || echo "No backups found"

That's it. mysqldump → gzip → timestamp → auto-cleanup. Runs in under a second on most databases.

What Each Piece Does

mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" — dumps every table, every row, every schema definition into a single SQL file. This is the standard MySQL backup tool and it's been reliable for decades.

| gzip — pipes the dump straight into compression without ever writing an uncompressed file to disk. A 200MB database compresses to maybe 15MB. On a cheap VPS with limited storage, this matters.

date '+%Y-%m-%d_%H-%M-%S' — timestamps every backup file. You get filenames like mydb_2026-05-20_03-00-01.sql.gz. When something breaks, you can see exactly which point in time each backup represents.

find ... -mtime +"$KEEP_DAYS" -delete — the line most people forget. Without this, your backup folder grows forever. -mtime +7 means "modified more than 7 days ago." Adjust KEEP_DAYS based on how much disk you have.

Stop Hardcoding Passwords

The script above works, but DB_PASS="your_password" sitting in a plain text file is a liability. In production, use a ~/.my.cnf file instead:

[client]
user=root
password=yourpassword

Then chmod 600 ~/.my.cnf and remove the -u and -p flags from the mysqldump command entirely. MySQL reads credentials from that file automatically. Nobody sees the password in ps aux output, nobody finds it in your bash history.

Schedule It

Open crontab -e and add:

0 3 * * * /home/user/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

That runs the backup every night at 3 AM and logs the output. If you want it every 6 hours instead:

0 */6 * * * /home/user/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

If you're not comfortable with cron syntax, I built a free cron job builder that generates the line for you — click the schedule you want, copy the output.

Variations I Actually Use

Back up ALL databases on the server:

mysqldump --all-databases | gzip > "${BACKUP_DIR}/all_dbs_${DATE}.sql.gz"

Copy the backup to a remote server (so it survives a full disk failure):

scp "${BACKUP_DIR}/${FILENAME}" backupuser@remote-server:/backups/

Send yourself an email when the backup runs (or fails):

Pair this with my email alert script and you'll get a notification either way.

The Part Nobody Mentions

Test your restores. A backup you've never restored is a backup that might not work. Once a month, spin up a test database and run:

gunzip < your_backup.sql.gz | mysql -u root -p test_database

If that command works, your backups are real. If it doesn't, you've been collecting dead files.

The full script with the line-by-line breakdown, the ~/.my.cnf setup walkthrough, and three more variations is at:

bashsnippets.xyz/snippets/mysql-database-backup.html

If you're running a database on a VPS without automated backups, take 90 seconds and set this up today. Future you will be grateful.

The Bash $PATH Debugger I Run Whenever I Get "Command Not Found"

Anguishe — Fri, 08 May 2026 18:04:51 +0000

Every experienced Linux user has been there: you install something, or move directories around, and suddenly command not found appears for tools you know are installed.

You check which, type, echo $PATH, and still waste 10-20 minutes hunting down the issue. I've done it more times than I care to admit — especially after fresh server setups or when cleaning up dotfiles.

That's why I built (and now constantly use) a Bash $PATH Debugger.

Paste your $PATH and get instant diagnosis

Here's how it works in practice:

Copy your current PATH: echo $PATH
Paste it into the tool
Get a full report + fixed version in seconds

Try it here: Bash $PATH Debugger

What the tool does

The debugger takes your raw $PATH string and analyzes every directory with these checks:

Existence: Does the directory actually exist on the filesystem?
Duplicates: Are you wasting lookup time with repeated entries?
Permissions: Are any directories missing execute permissions for your user?
Order: Shows the exact search priority (first match wins)
Clean output: Generates a cleaned, deduplicated export PATH=... line ready for .bashrc or .profile

It even highlights common problems like missing ~/.local/bin, collapsed entries after moves, or directories that exist but aren't in your current session.

Why this tool saves so much time

"command not found" (exit code 127) is one of the most searched Bash errors online. Yet most resources just tell you to export PATH=... manually without diagnosing why it broke.

This tool does the diagnosis for you. It's especially powerful on fresh VPS setups, after migrating user accounts, or when working with Docker/container environments where PATH behaves differently.

Real-world use cases

After a apt install or brew install that doesn't add itself to PATH properly
Debugging why a script works in one terminal but not another
Cleaning up an overloaded PATH that accumulated junk over years
Preparing a clean minimal PATH for production servers

Pro tip: Test on a clean VPS

One of my favorite workflows is spinning up a fresh $4-5/mo VPS, installing my usual tools, running them through the debugger, and copying the optimized PATH into my base server image.

Common variations & advanced usage

The tool also supports:

Relative path expansion
Handling of ~ and environment variables in PATH entries
Export formats for different shells (bash, zsh, fish compatibility notes)

Full interactive tool with live diagnosis, cleaned PATH generator, and detailed explanations:

https://bashsnippets.xyz/tools/path-debugger.html

Paste your PATH. Fix the problem. Move on.

I Built a Free Tools Directory for Linux Users Who Are Tired of Googling the Same Commands

Anguishe — Thu, 07 May 2026 20:51:35 +0000

The Problem I Keep Running Into

I've written the same bash script scaffolding at least 40 times. Every time I spin up a new automation, I start from scratch: add the shebang, remember the set -euo pipefail line, define variables, write the same error-handling block I always use, forget to add a usage message until the third time I run it wrong.

And don't get me started on chmod. I Google "chmod 755 vs 644" at least once a month, even though I know what it means. The octal-to-permission mapping just doesn't stick unless you're using it every single day.

So I built something to fix both of those problems — and it's turning into a whole directory of tools.

What I Built: bashsnippets.xyz/tools

bashsnippets.xyz/tools is a free directory of interactive tools for Linux users and developers. No signup. No rate limits. Works in the browser. Copy and go.

Right now it has two tools live, with a new one shipping every week:

1. chmod Permissions Builder

Click checkboxes for read/write/execute across owner/group/others. Get the exact chmod command instantly — both octal and symbolic — with a plain-English explanation.

Example output:

chmod 755 filename
chmod u=rwx,g=rx,o=rx filename

Owner: read + write + execute

Group: read + execute

Others: read + execute

If you've ever second-guessed whether a script needs 755 or 744, this eliminates the lookup step permanently.

→ Try the chmod builder

2. Bash Boilerplate Generator

Pick your script type (automation, backup, monitoring, deployment), toggle options (error handling, logging, dry-run mode, help message), optionally inject a snippet from the library, and get a production-ready .sh template with everything wired up.

No more blank files. No more copying the same header block from your last script.

→ Try the boilerplate generator

What's Coming Next

I'm shipping a new tool every week. The queue right now:

Cron Job Builder — visual cron syntax builder with plain-English output
Exit Code Lookup — paste an exit code, get the meaning instantly
systemd Unit File Generator — build service files without memorizing the spec

Each one solves a specific "I always Google this" problem.

Why I Built This (and Why It's Free)

I got tired of opening 6 Stack Overflow tabs every time I needed to do something I'd done 20 times before. These aren't complex problems — they're just pattern-matching tasks where the syntax is annoying to remember.

The tools are free because:

They're simple enough that paywalling them would be ridiculous
I want them to be genuinely useful, not VC-funded SaaS bloat
The snippet library (which the tools complement) has always been free

There's no business model. Just a side project that scratches an itch I have, and apparently a lot of other people have too based on the YouTube Shorts I've been posting.

Try It

bashsnippets.xyz/tools

If you spot bugs, missing features, or have ideas for new tools, drop a comment. I'm building this in public and genuinely want feedback from people who actually use bash day-to-day.

Stop Guessing 'chmod' I Built a Free Visual Permissions Builder for Linux

Anguishe — Thu, 07 May 2026 20:31:05 +0000

The Problem

You're about to deploy a script. You know you need the file executable, but readable only by the owner. You type chmod 754... or was it 744? Maybe 755?

You Google it. You find a Stack Overflow thread from 2011. You get it wrong anyway.

chmod's octal notation is one of those things every Linux user has to look up every single time — and the mental model for why 755 means what it means isn't obvious unless you've memorized the bit table.

I built a tool to fix that permanently.

The Tool: chmod Permissions Builder

🔗 bashsnippets.xyz/tools/chmod-permissions-builder.html

It's a free, no-login, browser-based tool. You click checkboxes for Owner, Group, and Others — read, write, execute — and it instantly generates:

The chmod octal command (chmod 755 filename)
The symbolic command (chmod u=rwx,g=rx,o=rx filename)
A plain-English explanation of what those permissions mean

No ads walls. No email required. Copy and go.

How chmod Permissions Actually Work

Before we get to the tool output, here's the bit math that makes it click once:

Each permission set (owner / group / others) is a 3-bit binary number:

Permission	Binary	Octal
`---`	000	0
`--x`	001	1
`-w-`	010	2
`-wx`	011	3
`r--`	100	4
`r-x`	101	5
`rw-`	110	6
`rwx`	111	7

So chmod 755 means:

7 = owner gets rwx (read + write + execute)
5 = group gets r-x (read + execute, no write)
5 = others get r-x

That's it. Once you see it as binary, it's never confusing again. The tool builds this table live as you click.

Common Permission Combos

Here are the most-used values and what they're for:

chmod 755 script.sh      # Executable script — owner can edit, others can run
chmod 644 config.conf    # Config file — owner can edit, others read-only
chmod 600 .ssh/id_rsa    # Private key — owner only, no one else
chmod 777 /tmp/shared    # Fully open (use sparingly, never on production)
chmod 700 ~/scripts/     # Private directory — owner only

How to Apply Permissions Recursively

The builder outputs a single-file command. If you need to apply permissions across a whole directory:

# Apply 755 to all directories, 644 to all files
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

Or use the -R flag (with care):

chmod -R 755 /var/www/html

⚠️ Never run chmod -R 777 on anything outside a throw-away sandbox. It removes all security boundaries.

Check Current Permissions Fast

Before changing anything, inspect what's there:

ls -la filename          # Single file
stat filename            # Verbose output including octal
ls -la /path/to/dir/     # Directory listing

stat shows you the octal directly — useful when you need to replicate permissions from one file to another:

stat -c "%a" filename    # Just the octal number

Try the Tool

If you set the wrong permissions on a web server config or SSH key, things break in ways that are slow to debug. Getting it right the first time matters.

→ Open the chmod Permissions Builder

No login. No install. Works on mobile too.

More free tools and copy-paste bash scripts at bashsnippets.xyz

Every bash script I write starts with the same 20 lines. So I made a generator for them.

Anguishe — Wed, 06 May 2026 21:00:43 +0000

There's a set of things every bash script should have at the top. Not "here are some nice-to-haves" — actual things that prevent real, bad, hard-to-debug failures:

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'

set -e makes the script exit immediately if any command returns a non-zero status. Without it, your script keeps running after a failure and you get compounding errors that are confusing to trace.

set -u makes the script error if you reference a variable that hasn't been set. Without it, $MYVAR being undefined silently evaluates to an empty string. That empty string goes into a path. That path gets passed to rm -rf. You see where this goes.

set -o pipefail makes the exit status of a pipeline reflect the first failure in the chain, not just the last command. broken_command | grep something would exit 0 without this flag, because grep succeeded even though the input was empty.

IFS=$'\n\t' prevents word splitting on spaces in filenames. Without it, a filename like my file.txt gets treated as two arguments.

This is what I call the mandatory header. I've forgotten parts of it enough times that I stopped trying to remember it and started generating it.

The Boilerplate Generator

You configure:

Script identity — name, description, author. These go in the comment block at the top so someone reading the script 6 months from now (probably you) knows what it's supposed to do.

Safety flags — each one is a checkbox with an explanation of what it does. `set -x` is there too for debug mode — I often add it temporarily when something isn't working, then remove it before deploying.

Features:

Timestamped log() function — stops you from using raw echo for output, which doesn't timestamp. When you're looking at a log file and everything just says "backup complete" with no time attached, you'll wish you had this.
CHECK / CROSS variables — adds CHECK="✓" and CROSS="✗" at the top, which is the convention across all BashSnippets scripts. Consistent visual output in the terminal.
Argument parser with --help and --dry-run — getopts-based. Dry run mode is something I use constantly during development to test a script's logic without actually writing/deleting/moving anything.
Lock file — prevents duplicate runs. If you're scheduling something with cron and the job sometimes runs long, without a lock file you can end up with two instances trying to write to the same output file.
Root check — exits cleanly with an error if the script isn't run as root, instead of failing halfway through with a permission error.
Trap on EXIT — runs a cleanup() function on exit or interruption, which you can populate with whatever teardown logic makes sense.

Snippet injection — you can pull in a script from the library (disk space warning, file backup, delete old logs, etc.) and have it dropped into the body of the generated boilerplate. So you're not starting from zero — you're starting from a working script wrapped in production safety.

What the output looks like

When you configure everything and click copy, you get a complete `.sh` file: shebang, comment block, safety flags, feature code, and your injected snippet (if any) in the main logic section. There's even a source comment pointing back to bashsnippets.xyz so your team knows where the template came from.

I use this myself. Every new script starts here.

Why this exists as a tool instead of a GitHub gist

Because I kept updating my gist as I learned new things, and then had five different versions floating around in different places. A tool with checkboxes forces me to be explicit about what I'm including and why, and the output is always current.

Try it: https://bashsnippets.xyz/tools/bash-boilerplate-generator.html

Free, no login, GitHub Pages. Generates clean `.sh` output you can paste directly into a file and start editing.

Stop Googling "what is exit code 127" There's a better way to handle it

Anguishe — Wed, 06 May 2026 20:57:35 +0000

Exit code 127 means "command not found." I know that now. But the first dozen times I saw it, I Googled it. Every time. Because exit codes are one of those things that are fundamental to bash scripting but never feel intuitive until you've been burned by them enough.

Here's a quick table of the ones that show up constantly:

Code	Meaning
0	Success
1	General error
2	Misuse of shell built-in
126	Command found but not executable
127	Command not found
130	Script killed with Ctrl-C
137	Process killed with SIGKILL (kill -9)
139	Segmentation fault
143	Process killed with SIGTERM

The rule for codes above 128: subtract 128 to get the signal number. 137 = 128 + 9 (SIGKILL). 143 = 128 + 15 (SIGTERM). Once you know that pattern, a lot of the high-numbered codes make sense.

But looking up the code is only half the problem

The other half is writing the error handler. And this is where most scripts fall short. They check `$?` after a command, but the handler is usually something like:

if [ $? -ne 0 ]; then
  echo "something went wrong"
  exit 1
fi

Which tells you almost nothing when you're looking at logs at 2am.

I built a tool that generates a proper handler for any code you give it.

The Exit Code Lookup tool

You go to https://bashsnippets.xyz/tools/bash-exit-code-lookup.html, type in a code — or click one of the common ones — and you get:

What the code means
The most likely causes (this is the part that actually saves time)
A copy-paste error handler in your choice of format: if/else block, case statement, or inline || fallback

The if/else output names the code explicitly, logs what failed, and exits with the same code so the calling process knows something went wrong. The case statement version is better if you're handling multiple possible outcomes. The inline `||` is what you want when you're doing something quick and you just need a fast bail-out.

One thing I added that I actually use myself: the quick-click buttons for the codes you see constantly. You don't have to type 127 — just click it, get the handler, copy it.

Common situation this actually helps with

You're writing a script that calls a binary. You want to handle the case where the binary isn't installed (127), the case where the binary exists but fails on the input (1), and the case where someone Ctrl-C'd it (130). Those three cases need different responses — log and exit, retry with different args, clean up and exit gracefully — and the case statement the tool generates is structured for exactly that.

The thing I keep adding to all my scripts now

trap 'echo "Script failed at line $LINENO with exit code $?" >&2' ERR

Put that near the top of any script that matters. When it fails — and things fail — you know exactly where and with what code. Pair it with the exit code lookup when you're not sure what the code means, and you cut debugging time significantly.

Try it: https://bashsnippets.xyz/tools/bash-exit-code-lookup.html

No signup. All 256 codes (0-255) are in there. The handlers are copy-ready and production-quality, not the half-baked one-liners you find on random Stack Overflow answers.

I got tired of deploying broken cronjobs, so I built a tool that generates them properly

Anguishe — Wed, 06 May 2026 20:54:04 +0000

Every linux user has a story. Mine is a backup script that silently failed for three weeks because the cron expression was right but the PATH wasn't set, so the script couldn't find tar. Backups looked like they were running. Nothing was actually being archived. I found out when I needed to restore a file.

That specific failure mode — cron jobs that pass silently but don't actually do anything — is one of the most annoying problems in Linux automation because there's no obvious error. The job runs. The exit code is 0. Your logs say nothing because you didn't add logging. And now you're debugging something that happened at 2am three weeks ago.

So I built a tool.

What it does

The Cron Job Builder at bashsnippets.xyz does three things that I always forget to do manually:

1. Builds the expression visually

You pick minute, hour, day of month, month, and day of week from dropdowns. It assembles the expression in real time. There are also quick presets — daily 2am, every 6 hours, weekdays 9am, monthly, every 15 minutes — for the schedules you actually use 90% of the time.

2. Wraps it in production-safe bash

This is the part that actually matters. The tool adds:

>> /var/log/cronjob.log 2>&1 — so stdout and stderr go somewhere you can read them later
SHELL=/bin/bash — because cron's default shell is not what you think it is
PATH=/usr/local/bin:/usr/bin:/bin — this is the one that burned me. Cron has a stripped-down PATH. Commands that work in your terminal fail silently in cron because the binary isn't in scope.
MAILTO=you@example.com — optional, but useful for catching failures you're not watching for
Lock file via flock — prevents a slow job from stacking on top of itself if it runs longer than the schedule interval

Every single one of these is a checkbox. You don't have to remember them — you just check what you need.

3. Shows the next 10 scheduled run times

So you can verify the expression is actually doing what you think it's doing before you paste it into crontab.

You can also inject a snippet from the library

The tool has a dropdown that lets you pull in a pre-built script from the BashSnippets library — file backup, disk space warning, delete old logs — and have it wrapped in the boilerplate automatically. So you go from "I want to back up my home directory nightly" to a full, copy-ready crontab entry in about 20 seconds.

Why I built this on a static site

The whole site is GitHub Pages. No backend, no database, no server-side anything. The cron expression parser, the next-run-time calculator, all of it runs in the browser. That means it loads fast, works offline if you've cached it, and I don't have to pay for compute just so someone can build a cron expression.

Try it: https://bashsnippets.xyz/tools/cron-job-builder.html

Everything on BashSnippets is free. No login, no email capture, no limit on how many times you use it. Just open it, configure it, copy the output.

If you've ever had a cronjob fail silently and had to debug it at an awkward hour, this is for you.

CoderLegion? I think so. . .

Anguishe — Wed, 06 May 2026 16:53:42 +0000

🚀 Check out my CoderLegion profile & latest post!

🏆 Points: 162 | 🎱 Badges: 5 | 👥 Followers: 0 | 📄 Posts: 3

Latest post: "I built a free bash script library because I kept Googling the same 10 scripts over and over"
Read it here: https://coderlegion.com/16878/i-built-a-free-bash-script-library-because-i-kept-googling-the-same-10-scripts-over-and-over

View my full profile: https://coderlegion.com/user/BashSnippets

Come join me!

My site went down for a few hours yesterday and my users knew before me

Anguishe — Mon, 04 May 2026 23:26:36 +0000

It happened to me.

My site — bashsnippets.xyz — had been down for six hours before I knew
about it. I found out because a reader emailed me. Not because I checked.
Not because I had monitoring. Because someone else had to tell me.

That's the kind of thing that sits with you.

The fix took 20 minutes to build. Here's exactly what I wrote and why
every piece of it matters.

The problem with checking manually

The natural instinct is to just open a browser and load the page.
But that has two failure modes:

You only check when you remember to
You don't check at 2am when it actually goes down

What you want is automated, logged, and running while you sleep.

Start with the one-liner

Before building the full script, understand the core command:

curl -o /dev/null -s -w "%{http_code}" https://yoursite.com

Run it. It prints one number. That number is your site's HTTP status code.

Here's what each flag does — and this is worth understanding
because you'll use these flags for a lot more than uptime checking:

-o /dev/null — tells curl to discard the response body entirely.
You don't need the HTML. You only need the status code.
Without this flag, curl dumps the entire page to your terminal.

-s — silent mode. Suppresses the progress bar and error messages.
Without this, curl prints download stats you don't need.

-w "%{http_code}" — write-out format. Tells curl to print only
the HTTP status code after the request completes.
This is the only output you care about.

Result: just the number. Nothing else. Clean, parseable, scriptable.

$ curl -o /dev/null -s -w "%{http_code}" https://bashsnippets.xyz
200

Status codes you need to know

Code	Meaning	What to do
200	Up and healthy	Nothing
301/302	Redirect — usually fine	Check it's intentional
404	Page not found	Check your URL
503	Server error — site is down	Investigate immediately
000	DNS failure / unreachable	Your server may be completely offline

The full script

Now wrap it in logic that tells you what the number means:

#!/bin/bash

CHECK="✓"
CROSS="✗"

URL="https://bashsnippets.xyz"
STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$URL")

if [ "$STATUS" -eq 200 ]; then
  echo "$CHECK $URL is up (HTTP $STATUS)"
else
  echo "$CROSS $URL returned HTTP $STATUS — check it"
fi

The $CHECK and $CROSS variables aren't required — you could hardcode
the symbols directly — but defining them at the top makes it trivial
to change the output format later and keeps the echo lines readable
at a glance.

Save this as uptime.sh in your home directory.

Make it executable

chmod +x ~/uptime.sh

chmod +x adds execute permission to the file. Without this,
bash treats it as a plain text file and refuses to run it.
This is the step people forget. Every time.

Test it manually before scheduling anything:

./uptime.sh
# ✓ https://bashsnippets.xyz is up (HTTP 200)

Schedule it with cron

A script you run manually is still manual monitoring.
The goal is automation — the script checks your site while you sleep.

Open your crontab:

crontab -e

Add this line:

*/5 * * * * ~/uptime.sh >> ~/uptime.log 2>&1

Breaking this down:

*/5 * * * * — run every 5 minutes. The */5 means "every 5th
minute of every hour of every day." Change to */1 to test it faster.

~/uptime.sh — the script to run. The ~/ expands to your
home directory — safer than a relative path.

>> ~/uptime.log — append output to a log file.
Using >> instead of > means each result adds to the file
rather than overwriting it. You want a history, not just the last result.

2>&1 — redirect stderr to stdout so errors also get logged.

Save and exit. Cron confirms: crontab: installing new crontab

Watch it run in real time

tail -f ~/uptime.log

tail -f watches a file and prints new lines as they're added.
Open this in a second terminal after setting up cron.
Within a minute you'll see the script run on its own —
no input from you, no trigger, just cron firing the script
and the result appearing in the log automatically.

That moment where the second line appears on its own —
that's the confirmation that automation is actually working.

The full copy-paste version

#!/bin/bash

CHECK="✓"
CROSS="✗"

URL="https://yoursite.com"   # ← change this to your site
STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$URL")

if [ "$STATUS" -eq 200 ]; then
  echo "$CHECK $URL is up (HTTP $STATUS)"
else
  echo "$CROSS $URL returned HTTP $STATUS — check it"
fi

Cron line to add with crontab -e:

*/5 * * * * ~/uptime.sh >> ~/uptime.log 2>&1

Full reference page with all variations:
→ bashsnippets.xyz/snippets/check-if-website-is-up.html

I post a new copy-paste bash script every week at bashsnippets.xyz.
All free. No signups. @BashSnippets on YouTube if you want to see these in 30-second form.

How do you monitor your sites? I'm genuinely curious what the rest of you are running 👇

DEV Community: Anguishe

Your Server Is at 97% CPU Right Now. Would You Know?

The Script

How the CPU Check Actually Works

The Thing About tee -a

Schedule It

Variations That Are Worth Adding

When This Isn't Enough

My Nginx Died at 2 AM and Nobody Noticed for 6 Hours. Now I Have a Watchdog Script.

The Script

Why systemctl is-active --quiet and Not Something Else

The Two-Level Failure Check

Setting It Up with Cron

What Else I Watch With This

Pairing This With Other Scripts

I Built a Free Tools Directory for Linux Users Who Are Tired of Googling the Same Commands

The Problem with Most Bash Resources

The Tools I Wish Had Existed

1. Bash $PATH Debugger

2. Cron Job Builder

3. chmod Permissions Builder

4. Bash Exit Code Lookup

5. Bash Boilerplate Generator

What's Coming Next

The Philosophy

Why I'm Building This in Public

I Lost a Client's Database on a $5 VPS. Here's the 12-Line Script That Would Have Saved It.

The Script

What Each Piece Does

Stop Hardcoding Passwords

Schedule It

Variations I Actually Use

The Part Nobody Mentions

The Bash $PATH Debugger I Run Whenever I Get "Command Not Found"

Paste your $PATH and get instant diagnosis

What the tool does

Why this tool saves so much time

Real-world use cases

Pro tip: Test on a clean VPS

Common variations & advanced usage

I Built a Free Tools Directory for Linux Users Who Are Tired of Googling the Same Commands

The Problem I Keep Running Into

What I Built: bashsnippets.xyz/tools

1. chmod Permissions Builder

2. Bash Boilerplate Generator

What's Coming Next

Why I Built This (and Why It's Free)

Try It

Stop Guessing 'chmod' I Built a Free Visual Permissions Builder for Linux

The Problem

The Tool: chmod Permissions Builder

How chmod Permissions Actually Work

Common Permission Combos

How to Apply Permissions Recursively

Check Current Permissions Fast

Try the Tool

Every bash script I write starts with the same 20 lines. So I made a generator for them.

There's a set of things every bash script should have at the top. Not "here are some nice-to-haves" — actual things that prevent real, bad, hard-to-debug failures:

This is what I call the mandatory header. I've forgotten parts of it enough times that I stopped trying to remember it and started generating it.

The Boilerplate Generator

You configure:

Script identity — name, description, author. These go in the comment block at the top so someone reading the script 6 months from now (probably you) knows what it's supposed to do.

Safety flags — each one is a checkbox with an explanation of what it does. set -x is there too for debug mode — I often add it temporarily when something isn't working, then remove it before deploying.

Features:

Snippet injection — you can pull in a script from the library (disk space warning, file backup, delete old logs, etc.) and have it dropped into the body of the generated boilerplate. So you're not starting from zero — you're starting from a working script wrapped in production safety.

What the output looks like

I use this myself. Every new script starts here.

Why this exists as a tool instead of a GitHub gist

Because I kept updating my gist as I learned new things, and then had five different versions floating around in different places. A tool with checkboxes forces me to be explicit about what I'm including and why, and the output is always current.

Try it: https://bashsnippets.xyz/tools/bash-boilerplate-generator.html

Free, no login, GitHub Pages. Generates clean .sh output you can paste directly into a file and start editing.

Stop Googling "what is exit code 127" There's a better way to handle it

Exit code 127 means "command not found." I know that now. But the first dozen times I saw it, I Googled it. Every time. Because exit codes are one of those things that are fundamental to bash scripting but never feel intuitive until you've been burned by them enough.

Here's a quick table of the ones that show up constantly:

The rule for codes above 128: subtract 128 to get the signal number. 137 = 128 + 9 (SIGKILL). 143 = 128 + 15 (SIGTERM). Once you know that pattern, a lot of the high-numbered codes make sense.

But looking up the code is only half the problem

The other half is writing the error handler. And this is where most scripts fall short. They check $? after a command, but the handler is usually something like:

Which tells you almost nothing when you're looking at logs at 2am.

I built a tool that generates a proper handler for any code you give it.

The Exit Code Lookup tool

The Thing About `tee -a`

Why `systemctl is-active --quiet` and Not Something Else

Safety flags — each one is a checkbox with an explanation of what it does. `set -x` is there too for debug mode — I often add it temporarily when something isn't working, then remove it before deploying.

Free, no login, GitHub Pages. Generates clean `.sh` output you can paste directly into a file and start editing.

The other half is writing the error handler. And this is where most scripts fall short. They check `$?` after a command, but the handler is usually something like: