Snippets and guides solve different problems. A snippet is one task and one script: check disk space, kill a process on a port, dump a database. You land on it from a search, copy the script, schedule it, and move on. A guide is the layer above that — an end-to-end workflow that composes several scripts into a system, with the judgment about which to run, in what order, and why. Snippets answer “how do I do X”; guides answer “what should I actually run on a production server, and how do these pieces fit together.”
Guides are for the moment you have outgrown copy-paste. You have a server that matters, a handful of scripts already on cron, and the questions have shifted: which checks do I actually need, how do detection and alerting and recovery connect, what does a sane baseline look like for a box I just provisioned. The individual snippet pages cannot answer that — each describes one tool in isolation. A guide is where the cross-cutting decisions live.
Every guide here is built from scripts you can also find as standalone snippets, so nothing is locked behind the long-form. The guide adds the sequencing and the reasoning; the snippets stay the reference you return to when you need just the command.
pillar guide · sysadminList Open Ports on Linux: With the Process, Without Root, and Without netstat
"List open ports" is three questions: what listens, who owns it, is it reachable. ss flags, the no-root -e trick, lsof, fuser, nc, docker-proxy and an audit.
You leave able to answer the port question the way it is actually asked: which process has it, even when ss shows a blank process column because you are not root; why the address column matters more than the port; what a listener owned by docker-proxy really is; and a script that turns the list into CSV and tells you once when something new starts listening.
Read guide →pillar guide · sysadminAuto-Restart a Stopped Service on Linux: systemd Restart=, Cron Watchdogs, and the Start-Limit Trap
"Down" is three states: crashed, stopped, or hung. Restart crashes with systemd Restart=, clear the start-limit trap, probe hung services, alert once.
You leave knowing which of the three kinds of "down" you have before you touch it: the exit code 4 that makes a watchdog restart a unit that does not exist, why Restart=always did nothing for a display manager that never exited, the "start request repeated too quickly" state that makes systemctl start refuse until reset-failed, and a watchdog script that probes for the hung case and sends one alert per outage.
Read guide →pillar guide · sysadmin25 Bash Scripts Every Linux Sysadmin Needs
25 bash scripts that prevent the most common server failures: disk full, SSL expiry, failed services, bad permissions. Copy-paste ready and cron-schedulable.
You walk away with a provisioning checklist, not a reading list: the exact scripts that prevent a disk-full outage, a silent SSL expiry, a service that died over the weekend, and a permission hole on a fresh web root. It is organized by failure mode, so you can jump straight to the problem you are trying to prevent and leave with the cron entry that prevents it.
Read guide →pillar guide · sysadminBash Scripting for CI/CD Pipelines: GitHub Actions, Deploys, and Docker
A pipeline reported every step green and deployed broken code, because the build step piped output through tee and bash returned the exit code of tee — always zero. This guide covers the four CI-specific failure modes, safe bash headers, secret validation, PIPESTATUS and pipefail, Docker entrypoints, atomic symlink deploys, and debugging with set -x.
You leave with a deploy script that fails loudly, rolls back automatically, and passes a health check before marking success — not one that ships broken builds under a green checkmark.
Read guide →pillar guide · sysadminBash Text Processing: find, grep, sed, and awk for Logs and Config Files
find locates, grep searches, sed transforms, awk summarizes. The order that turns a log or a config tree into an answer, and the gotchas that fail quietly.
You leave with the pipeline order that keeps text processing boring: scope the blast radius with find, confirm the match with grep, transform with sed or awk under an undo, and verify before you trust it — plus the 2am incident one-liner that ranks your errors most-frequent-first.
Read guide →pillar guide · sysadminDiagnosing a Hung Process: The Commands to Run Before You Kill It
A hung job never exits and never logs why. The commands that show what it is blocked on (state, wchan, syscall, files, sockets) before a kill erases the clues.
The state letter tells you which kind of stuck: S responds to signals, D cannot be killed at all — which is every "kill -9 is not working" report there has ever been. Read wchan and the syscall without root, check the socket queues, and capture the lot before you kill it.
Read guide →pillar guide · sysadminThe Safe Bash Script Template: What set -euo pipefail Actually Changes
set -euo pipefail is three promises, each with places it silently does nothing. What each flag does, where errexit quits, and the ERR trap that names the line.
The flag missing from almost every pasted strict-mode line is the E. Without set -E your ERR trap never fires inside a function, so the script exits 1 and tells you nothing — plus the local x=$(cmd) that swallows a failure whole, and the template that closes both gaps.
Read guide →pillar guide · sysadminBash Scripts That Survive Cron: Locking, Timeouts, and Retries
A script that works when you run it can still die quietly on cron. The three failure modes (overlap, hang, transient error) and the guard that stops each one.
The three ways cron jobs die quietly — overlap, hang, transient failure — and the guard that stops each.
Read guide →pillar guide · sysadminUbuntu 26.04: What Breaks in Bash Scripts
Upgrading 24.04 to 26.04 swaps in sudo-rs and Rust coreutils: rules get dropped, exit codes and errors change. Each change reproduced, plus a pre-upgrade check.
sudo-rs drops sudoers rules with wildcards in arguments, timeout -s KILL exits 124 instead of 137, ln says Already exists instead of File exists, and tail -n1 f >> f never stops. Each change run side by side in 24.04 and 26.04 containers, with the order to check a server before do-release-upgrade and the two commands that switch back.
Read guide →pillar guide · sysadminBash Error Messages, Decoded
Nine bash error messages decoded from real runs: what the shell was doing, the 60-second check that names the cause, the fix, and the order to read any error.
command not found, Permission denied, bad interpreter, unary operator expected, unbound variable, unexpected token, Argument list too long, No space left on device and Connection refused, each reproduced on this machine. You leave knowing what the shell was doing when it printed each one, the one command that tells its causes apart, and the four-step order that finds the cause of almost any failure.
Read guide →pillar guide · sysadminsystemd Timers vs Cron: Missed Runs, Overlaps and Failure Alerts
Cron skips runs the machine was off for and drops output with no mail server. systemd timers catch up with Persistent=, log to the journal and alert on failure.
A weekly cron job on this laptop ran on one Sunday in four; the systemd timer next to it ran on all four, three times within a minute of boot. You leave knowing what Persistent=true really does, why a slow oneshot job is queued rather than skipped, how to get an alert from OnFailure=, the day-of-month plus day-of-week rule that makes some crontab lines impossible to convert literally, and when cron is still the right choice.
Read guide →pillar guide · sysadminShell Scripts That Talk to APIs
Make curl fail when the API fails, parse the response with jq instead of regex, and alert to Slack when it breaks — the reliable pattern for calling an HTTP API from bash.
curl that fails loudly, jq that never lies, and a Slack alert when either breaks — in one script.
Read guide →