🔍Module 6 — Finding Things: find and grep

2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
3
4:2026-09-02 10:04:44 ERROR Connection to db-01 refused
5:2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
6:2026-09-02 10:04:47 error retry 2 failed: connection refused

(First command: only the two uppercase ERROR lines; shown above from -i onward.)

What to read out of it:

• The case-sensitive search missed a real error — the lowercase error line a hurried developer logged. Real logs are inconsistent; -i is the difference between "2 errors" and the truth. This single character has changed incident timelines.
• -c counts matching lines, not occurrences — a line saying "error error error" counts once. Precision about what is being counted is a habit interviewers test.
• -n's line numbers are for your editor: nano +5 app.log jumps straight there.

2026-09-02 10:03:15 WARN  Slow response from db-01 (1200ms)
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
HOME=/home/zaeem

What to read out of it:

• Dropping INFO left the story: a warning, then the failure, then the retries. Subtracting noise is often faster than describing signal — -v earns its keep in incident work hourly.
• The chain kept the lowercase retry line — -v Retry is case-sensitive and the sloppy line says retry. The same inconsistency that bit you in A1.1, now biting the exclude side. Fix: grep -vi retry. Logs punish assumptions symmetrically.
• env | grep — the pattern you will type most: any command's output, filtered. (Your env line may differ; some systems also match XDG_CONFIG_HOME and friends — more lines is normal.)

./app/config/app.conf:db_host=db-01
./app/logs/app.log:2026-09-02 10:03:15 WARN  Slow response from db-01 (1200ms)
./app/logs/app.log:2026-09-02 10:04:44 ERROR Connection to db-01 refused
./app/config/app.conf
./app/logs/app.log

What to read out of it (entry order can differ between machines — the filesystem decides):

• Every match now wears its filename — and the answer spans both config and logs: db-01 is configured in one place and failing in another, which is precisely the shape of real diagnosis.
• -l collapsed the same search to two names. Feed that to other commands (-exec, xargs, editors) and you are operating on "all files mentioning X" — a set you computed rather than guessed.

2026-09-02 10:04:47 error retry 2 failed: connection refused
2026-09-02 10:05:00 INFO  Failover to db-02
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
2026-09-02 10:05:00 INFO  Failover to db-02
2026-09-02 10:05:01 INFO  Connection to db-02 established

What to read out of it:

• -B 1 answered the question in two lines: the failover followed the final failed retry. Cause, adjacent to effect.
• The second command's $ anchored the match to line-ends — your first deliberate regex character, formally introduced in the next Part. Notice the three refused-lines' contexts merged into one block: overlapping context regions are printed once, not duplicated.

grep searches text — files or stdin — for lines matching a pattern (fixed string or regular expression) and prints the matching lines. The name is from the old editor command g/re/p: globally search for a regular expression and print. Core flags: -i case-insensitive, -v invert, -r recursive, -n line numbers, -c count lines, -l names only, -w whole words, -A/-B/-C context, -E extended regex. As a pipeline filter it is the most-composed command on any Linux system.

The details that separate candidates: the exit-code contract (0 match, 1 no match, 2 error) and what it means for scripting; -c counting lines-not-occurrences; and one incident habit — -i first on human-written logs, because log level spelling is never consistent.

Chain an include with an exclude: grep 'apple' fruits.txt | grep -v 'orange' — first stage passes lines mentioning apple; second removes those also mentioning orange. Both stages accept full regexes, -i applies per-stage, and the chain extends indefinitely.

The details that separate candidates: mentioning the single-command alternatives for interviewers who push — grep -E 'apple' file | grep -vE 'orange|pear' for multiple excludes, or awk for conditions grep can't express (awk '/apple/ && !/orange/' — Module 7); and noting each stage is a concurrent process, so the chain scales to huge streams without memory cost.

grep -r 'the text' /path/ for a whole tree (add -l for filenames only, -n for locations); grep 'the text' file1 file2 file3 or a glob for a known set. For code trees, grep -rn --include='*.conf' narrows by filename pattern while searching content.

The details that separate candidates: choosing output form by question — -l for "which files", -n for "where exactly", -c for "how widespread"; and the honesty note that content search is O(everything) — for repeated searching at scale, purpose-built indexers exist, but grep -rl is the zero-setup answer that always works.

8
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
2026-09-02 10:03:15 WARN  Slow response from db-01 (1200ms)
2026-09-02 10:04:44 ERROR Connection to db-01 refused

What to read out of it:

• All 8 lines start with 2026 — ^ turned "contains" into "starts with", the standard trick for matching log timestamps and config keys (^db_host won't match # db_host comment… wait, it will match db_host_backup — anchors and word-ends combine: ^db_host=).
• db.01 matched db-01 — the . stood for the hyphen. It would equally match db 01, db801, dbX01: power and imprecision together. To match a literal dot, escape it: \. — the unescaped-dot bug classically bites IP-address patterns, where 10.0.0.1 happily matches 10a0b0c1.

2026-09-02 10:03:15 WARN  Slow response from db-01 (1200ms)
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:05:00 INFO  Failover to db-02
2026-09-02 10:05:01 INFO  Connection to db-02 established
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused
8

What to read out of it:

• One class, [12], covered both hosts — and pointedly did not match the 5432 in the config or anything else. Classes are precision instruments; . is a shotgun.
• The [0-9]{4}-[0-9]{2}-[0-9]{2} date shape is your first reusable regex — it appears in log tooling everywhere. Say it aloud as the crossword clue and it stops being line noise.
• Try the middle command without -E: zero matches, because basic grep hunts a literal plus sign. Same pattern, two dialects — when a regex mysteriously fails, "which dialect am I in?" is question one.

2026-09-02 10:03:15 WARN  Slow response from db-01 (1200ms)
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:44 ERROR Connection to db-01 refused
2026-09-02 10:04:45 ERROR Retry 1 failed: connection refused
2026-09-02 10:04:47 error retry 2 failed: connection refused

What to read out of it:

• The first three lines are the alternation's: it caught the WARN line the ERROR searches always missed — severity filters in one pattern. Note what it did not catch: the lowercase error line, because ERROR|WARN is still case-sensitive. Alternation widens the pattern, not the casing.
• The last three lines are -wi's: every error line regardless of case — and it would ignore an errors_total metric line, since word boundaries end the match at the word's edge. Cheap precision; most log searches want it.

-v (invert match). The distractors are the other daily flags — -i (ignore case) and -c (count) — so the question is really testing whether you have used grep or merely read about it.

The details that separate candidates: in the live follow-up, combining them fluently (grep -vic pattern — count of non-matching lines, case-insensitive) and knowing -v operates on whole lines, which is why removing a word from output is sed's job, not grep's.

Published Linux question banks barely test regex directly — it hides inside grep/sed/awk questions and in live exercises ("write a pattern that matches an IP address", "why does your pattern match too much?"). The high-yield preparation: be able to write, on a whiteboard, the date pattern [0-9]{4}-[0-9]{2}-[0-9]{2}, an anchored key match ^db_host=, an alternation ^(ERROR|WARN), and to explain the three classic bugs — unescaped dot, glob-star confusion, and unbracketed alternation. Interviewers care less about exotic syntax than about whether you know what your pattern actually matches.

./app/logs/app.log
.
./app
./app/config
./app/logs
./notes
./app/config/app.conf
./notes/todo.txt
./notes/old.txt

What to read out of it (entry order can differ between machines — the filesystem decides):

• The glob found the log wherever it lived — no need to know the depth. Compare Module 5's *.log, which only sees the current directory: find is the glob that descends.
• -type d listed . itself — the start point is part of the walk. Scripts that process find output learn to expect it.
• The -o line returned both kinds. One subtlety to bank for C4: AND binds tighter than OR, so mixing -o with actions needs parentheses — the classic trap detonates in that section.

./app/config/app.conf
./app/logs/app.log
./notes/todo.txt
./notes/old.txt
./app/logs/app.log

(First three lines: the fresh files from the -mtime -1 run. Line four: the back-dated file, alone under -mtime +1. Last line: the size test's single hit. Order within each group may differ.)

What to read out of it:

• old.txt — back-dated two days in setup with touch -d (Module 3's timestamp-setting, weaponized for testing) — fell past the +1 boundary exactly as designed. You now have a private time machine for testing date logic before trusting it in cleanups.
• Only the log exceeded 100 bytes. On a real host, find /var -size +500M -type f is the first command of every disk-full incident (Module 12 makes it a ritual).

/usr/bin/fusermount3
/usr/bin/sudo
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/passwd
/usr/bin/su
/usr/bin/umount
...

What to read out of it (your list will vary slightly with installed packages):

• Every name here is Module 4 vocabulary: passwd and sudo you predicted; mount/umount (Module 12), su, and the password-adjacent chfn/chsh/gpasswd complete the usual suspects. A dozen-odd entries is healthy; this list is supposed to be boring.
• The 2>/dev/null (Module 5) discards permission-denied noise from unreadable corners — the standard companion of any wide find. On a security sweep proper, you'd keep stderr and read it: unreadable directories are themselves findings.

8 ./app/logs/app.log
 1 ./notes/todo.txt
 0 ./notes/old.txt
 1 total
0

What to read out of it:

• The -exec ran wc per file; the xargs version handed all txt files to one wc, which is why a total line appears — one invocation, many arguments. Per-file vs batched is invisible at three files and decisive at three hundred thousand.
• -print0 | xargs -0 is one memorized unit: paths separated by null bytes, immune to spaces and newlines in names. Plain find | xargs corrupts on the first release notes.txt it meets.
• The delete of nothing succeeded silently, exit 0 — find's verdict is about the walk, not the match count. Automation wanting "fail if nothing matched" must count results itself (a Module 10 pattern).

find path tests walks a directory tree live, testing each entry: -name '*.conf' (glob, quoted), -iname case-insensitive, -type f/d, -mtime/-mmin for age, -size +100M, -user/-perm for ownership and mode; tests AND by default, -o for OR, ! to negate. It streams results as the walk proceeds and can act en route with -exec/-delete.

The details that separate candidates: contrasting find (live walk, always true, O(tree)) with locate (indexed, instant, possibly stale); one composed real command — "find /var/log -name '*.gz' -mtime +30 -delete, after a -print dry run"; and the -mtime bucket subtlety, which almost nobody volunteers and every senior recognizes.

find . -type f -mtime -1 -print0 | tar -czf recent.tar.gz --null -T - — find selects (null-separated for hostile filenames), tar's -T - reads the file list from stdin. The exclusion variant inserts -not -path './tmp/*' before the tests. Simpler-but-fragile spelling interviewers also accept: tar -czf recent.tar.gz $(find . -type f -mtime -1) — worth offering with its caveat (word splitting mangles spaced names; argument limits cap huge lists).

The details that separate candidates: knowing why the naive $(...) version breaks (M5's word splitting) and reaching for -print0/--null unprompted; the -mtime -1 vs -mtime 1 distinction; and mentioning the dry-run ritual before anything destructive touches the selection.

-mtime -1 — with the minus sign meaning "less than one 24-hour unit ago". The distractors are all real: -mmin is minutes (-mmin -1440 is the precise 24-hour spelling), -atime tests last read, -ctime last inode change — Module 3's three timestamps, resurfacing as find tests.

The details that separate candidates: the sign grammar (-1 less-than, +1 more-than, bare 1 the 24–48h bucket) stated crisply, and mapping atime/ctime back to their meanings instead of guessing — the MCQ is really a Module 3 exam in disguise.

/home/zaeem/search/app/config/app.conf
1

What to read out of it (your home path will differ):

• The indexed file appeared instantly. The file you created after updatedb produced nothing and exit code 1 — locate is not lying, it is answering from its snapshot, faithfully.
• Run sudo updatedb again, and locate brand-new.txt finds it. The whole tool in one experiment: an index, a rebuild schedule, and a freshness window you must always mentally subtract.

./app/config/app.conf
./app/logs/app.log

What to read out of it:

• Line one: only the conf file — the log also contains db-01 but failed the -name '*.conf' test. Metadata narrowed, content confirmed.
• Line two composes three selections — recency, file-ness, content — into one incident question: "what recent files talk about errors?" This composition habit, more than any single flag, is what Module 6 is for.

A single number — anywhere from 0 to a few dozen depending on the machine's recent history (a fresh VM may show few; a hand-tended server, many).

What to read out of it:

• This is drift detection in embryo: "what configuration changed this month?" is the first question after "it worked last month". Module 9's package tools will let you ask the sharper version — "changed from what the package shipped".
• Unprivileged, some of /etc was unreadable; the discard kept output clean while the count stayed honest for what you can see. Run with sudo and compare counts — the delta is the permission-protected zone.

locate pattern searches a pre-built filename index — near-instant regardless of disk size — with the index refreshed by updatedb, normally on a daily schedule (sudo updatedb forces it). The trade is explicit: speed for freshness. Files newer than the last rebuild are invisible; deleted files linger. find is the live-walk complement: always current, cost proportional to the tree.

The details that separate candidates: stating the trade as a decision rule — locate for "where does this thing usually live?", find for anything feeding automation or incident response; knowing updatedb respects permission boundaries (users can't locate files they couldn't see); and that minimal server images often omit locate entirely, so find fluency is the portable skill.

find . -type d -empty -exec rmdir {} \; — select directories, test emptiness, remove each. (Modern spellings also accepted: -empty -delete, which processes depth-first automatically, or add -depth with rmdir so children go before parents.)

The details that separate candidates: explaining why rmdir is the safe effector here — Module 2's "timid tool" refuses anything non-empty, so even a botched selection can't cascade; spotting the depth-order subtlety (a directory containing only empty directories empties as its children go); and reciting the dry-run ritual — -print first, always — before any find that deletes.

Ticket text: "Monitoring shows /var grew ~40 GB since yesterday on vm-app-2. Find what appeared or grew, without installing anything."

Worked answer: two sweeps, composed from C2. Recent and large first: sudo find /var -type f -mtime -1 -size +500M -exec ls -lh {} + 2>/dev/null — files both new-ish and big, human-readable sizes for the ticket. If that's quiet, drop the size test and sort the survivors by size: sudo find /var -type f -mtime -1 -size +50M -exec ls -l {} + | head -40. Typical culprits announce themselves by path: a log that lost its rotation (/var/log/app/app.log at 38 GB), a runaway core-dump directory, a cache. Then the content question — tail -50 the giant log (Module 3) to see what it's screaming about, because the disk symptom is usually a symptom of that. Module 12 adds du-based triage; the find version works everywhere today.

Ticket text: "Intended: delete .tmp files older than 7 days under /srv/staging. Result: /srv/staging is empty. Explain precisely, and give the replacement procedure." The command that ran: find /srv/staging -delete -name '*.tmp' -mtime +7

Worked answer: mechanism — find evaluates its expression left to right per file, while walking; -delete was the first term, so it fired unconditionally on every path visited, and the name/time tests were never consulted (they stood after the action, like a signature line after the demolition order). Not a bug: documented behaviour plus fatal ordering. Replacement procedure, verbatim into the runbook: 1) build the selection with no action: find /srv/staging -name '*.tmp' -mtime +7 -print; 2) read the list — count it, spot-check it; 3) re-run the identical expression with -print replaced by -delete (order preserved: tests first, action last); 4) for anything beyond .tmp files, prefer quarantine over deletion: -exec mv -t /srv/staging/_to_delete/ {} +, empty it a week later. And restore staging from backups — Module 3's rule about what deletion means has not softened.

Ticket text: "We migrated from db-01 to db-02 last quarter. Things keep 'mysteriously' connecting to db-01. Audit /etc and /srv/app on this host for every file still referencing it."

Worked answer: content sweep with filenames as the deliverable: sudo grep -rl 'db-01' /etc /srv/app 2>/dev/null. Then precision passes on the hits: grep -n 'db-01' each_file for exact lines, and -w if db-01x style near-names exist. Add the metadata angle for the report: ls -l each offender — the modification dates tell you which are pre-migration fossils and which were edited after the migration (someone re-adding the old host is a different, more interesting problem). Watch for false positives worth excluding (grep -rl 'db-01' | grep -v '\.bak$'), and for the one habit that prevents the recurrence: config in version control, where this audit is git grep and runs in milliseconds.

Ticket text: "Compliance sweep item 4.1.3: no file under /etc may be world-writable. Produce the evidence, and explain what you'd do with a hit."

Worked answer: the query is a -perm grammar exercise — "world-writable" means the others-write bit is set, whatever else is: sudo find /etc -type f -perm -o+w -exec ls -l {} + (symbolic spelling of "at least o+w"; -perm -002 is the octal twin). Empty output is the evidence — capture it with the command line and timestamp into the ticket. On a hit: ls -l is already in hand; identify the owner and the writing process (why is it world-writable — lazy chmod 777 from an old incident?), fix with the narrowest change (chmod o-w, Module 4's dictum), and check the same path across the fleet — one host's misconfiguration is usually a template's (Module 4's orange callout, in practice). Bonus points in the compliance answer: schedule the sweep and diff its output over time, converting a one-off audit into monitoring.