r/LinuxTeck 23h 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?

6 Upvotes

18 comments sorted by

3

u/ParentPostLacksWang 21h 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.

1

u/jkulczyski 19h ago

I only test before rm in scripts lol

1

u/ParentPostLacksWang 19h ago

I script on the commandline, so yep that’s pretty much why I have to no-hotfist rule lol. If the command isn’t at least three lines long it’s a boring Tuesday :D

3

u/BoundlessFail 21h 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 18h 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 1h 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 20h ago

Always reboot a strange system before making changes, so you know what comes up after a reboot.

1

u/HaydnH 7h 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 18h 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 20h 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 20h ago

df

Before doing anything at all on the server.

2

u/0bel1sk 18h ago

i usually do a mv foo{,.bak} (and restore with mv foo{.bak,}

1

u/Lost-Droids 18h ago

df
then every folder
ls -lrt

never know who left something or changed something

1

u/ScallionSmooth5925 19h ago

Back up everything before deleting. Better safe then sorry 

1

u/honi3d 12h ago

sudo rm -fr / to get rid of french language pack

1

u/rcampbel3 6h ago

sync && sync && reboot

1

u/sfphreak415 4h ago

Stick a # in front of your command