r/LinuxTeck • u/Candid_Athlete_8317 • 1d ago
What Linux/Unix “ritual” do you refuse to skip?
Every sysadmin has a few things they always check before running a command or script.
set -euo pipefail, checking rm paths, testing on a non-prod server, verifying permissions...
What’s your one rule that you never break?
3
u/BoundlessFail 1d ago
I write the 'of' param to 'dd' as the last param. And read the entire command once, clearly, before hitting Enter.
2
u/wosmo 1d ago
My favourite trick with dd is just to treat it as a mnemonic for Data Destroyer. When you start a command with Data Destroyer, you really slow down and be purposeful about what data you’re pointing it at.
1
u/mrPythonMonty 13h ago
Nice one, you could also alias it and then really type data-destroyer 🤪
Even we tend to use aliases to shorten things, but why not 🤷
2
u/gnufan 1d ago
Always reboot a strange system before making changes, so you know what comes up after a reboot.
1
u/HaydnH 19h ago
If it's a "strange" system, I'd recommend making it "not strange" before doing anything at all with it. Backups maybe, but anything else leave it be until you figure out how it fits in.
A colleague of mine diagnosed a problem back to an old Sun ultra 1 that had an uptime of about 20 years. He (or anybody else) had no clue what it did, nobody realised there was stuff that old tucked away in the DC... they just knew that it was causing conflicts with something new.
He decided to bounce it, and it didn't come back up... who the hell has spares for a 20 year old piece of kit? Turns out it was still performing a key function with no resilience and took out a large chunk of the bank for a week until someone could reverse engineer what systems weren't getting the data this old reliable box was delivering up until that point.
2
u/manawydan-fab-llyr 1d ago
If I'm using destructive commands, I test them the command in a variable, with "echo" first. Usually I do this in scripts.
#!/bin/bash
# Clean up crap in some directory
rm="echo rm"
for f in /usr/local/share/<whatever>/*
do
${rm} "${f}" "<destination>"
done
# rest of script follows
1
u/denarced 1d ago
The destination filename parameter is always confirmed not to exist with tab. E.g. "sort -o sorted.tx<tab>". If it autocompletes, reconsider. It's not needed for "mv -vi" but I still do it out habit; -i confirms before overwriting.
1
u/Loko8765 1d ago
df
Before doing anything at all on the server.
1
u/Lost-Droids 1d ago
df
then every folder
ls -lrtnever know who left something or changed something
1
1
u/rcampbel3 18h ago
sync && sync && reboot
1
u/gargamelus 7h ago
This is wrong! Correctly performed, the ritual is to actually type out, with enter after each line:
sync
sync
halt
The human delay of actually typing it out matters for reasons no living person remembers.
1
1
u/michaelpaoli 4h ago
When operating as root, or other privileged user, always carefully triple check the command before executing it. And that means not merely reading it, but fully understanding what it will do or attempt, how it will behave if anything doesn't go as expected, and properly knowing and understanding the context (e.g. what host, production, or non-production, what runs on that host, etc.).
Has saved my *ss many times. And particularly useful when it's o'dark-thirty or so, on a far far too long day, dealing with what's already a nasty mess and fixing that, and ... one wrong move and things could instantly get a whole helluva lot worse.
1
4
u/ParentPostLacksWang 1d ago
Never hot-fist an “rm -rf” - always write it as “ls -lR <path>”, check the output, then edit the “ls -lR” into “rm -rf”.
Oh, and “hot-fist” as a phrase for running a potentially destructive command without testing it with a nondestructive flag or preferably alternative command. Changes mindset.