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 is listening, who owns it, and is it reachable — and each needs a different command. ss with the filters and flags that matter, the -e trick that names the owning service without root, /proc/net/tcp by hand, lsof and fuser for the PID, nc and /dev/tcp for one port, what docker-proxy hides, and a CSV audit script that alerts once when a new listener appears.
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 different states — crashed, stopped on purpose, or running but not answering — and a watchdog that checks systemctl is-active handles exactly one of them. Let systemd restart crashes with Restart=, clear the start-limit trap that makes systemctl start refuse, probe for the hung case, and alert once per outage instead of once per minute.
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
The 25 bash scripts that prevent the most common server failures — disk full, SSL expiry, failed services, insecure permissions. Copy-paste ready, cron-schedulable, no installs required.
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
The four commands that turn an unreadable log or a tree of config files into an answer — find to locate, grep to search, sed to transform, awk to summarize. The order matters, and the gotchas are the reason most one-liners do the wrong thing 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, never logs, and never tells you why. The exact commands to find out what it is blocked on — process state, wchan, syscall, open files, sockets — and why killing it first destroys the only evidence you had.
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
Strict mode is three separate promises, not one incantation — and there are places every one of them silently does nothing. What each flag really does, where errexit gives up, and the ERR trap that tells you which line died.
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 isn't the same as one that survives unattended on cron. The three ways cron jobs die quietly — overlap, hang, transient failure — and the guards that stop each one.
The three ways cron jobs die quietly — overlap, hang, transient failure — and the guard that stops each.
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 →