20% of Linux Commands You'll Use 80% of the Time (Real-World Example)

Main ideas, concepts, and lessons

• Use Linux commands to turn the terminal into a troubleshooting superpower, especially for real-world scenarios like debugging production issues.
• Practice safely and consistently without setting up a full Linux machine:
  • Use Docker Desktop with a pre-built custom Docker image that already includes the needed Linux environment/tools.

Core Linux workflow for diagnosing an outage

1. Confirm you’re in the expected Linux environment.
2. Navigate to the application’s log directory.
3. Inspect logs, filter for relevant errors, and save results for later.
4. Identify the failure pattern (e.g., database connection refused).
5. Locate database configuration files across the filesystem.
6. Compare current vs. backup configs to find the erroneous setting.
7. Verify whether the expected service/port is actually reachable.
8. Fix configuration by editing the file.
9. Adjust permissions if the config is read-only.
10. Re-test after changes and exit the container.

---

Methodology / step-by-step instructions (detailed)

A) Set up a Linux practice environment using Docker

• Install Docker Desktop

  • Download Docker Desktop for Windows or Mac.
  • Start Docker Desktop so it runs in the background.

• Start a Linux container from a custom image

  • Open your system terminal (Windows Terminal / macOS Terminal).
  • Run the command to pull the creator’s custom Linux Docker image (using the link from the video description).
  • Run the image as a container using the command that starts an interactive Linux terminal inside it.

• No prior Docker knowledge required

  • Just run the provided image commands.

B) Validate the Linux environment

• Use:
  • uname
• Purpose:
  • Confirm the OS/environment type (Linux).

C) Diagnose a production issue by inspecting application logs

1. Check your current directory

   • Command: pwd
   • Lesson: know where you are in the filesystem first.

2. Navigate to the application log folder

   • Command: cd <path>
   • Example path used: /var/sl/log/sl/application (as shown in subtitles)

3. List files in the log directory

   • Command: ls

4. View extended details (permissions, sizes, etc.)

   • Command: ls -l

5. Read log file contents

   • Command: cat <filename>
   • Lesson: inspect raw errors directly when you see failures.

6. Filter logs to specific error lines

   • Use pipes to connect commands (output from one command becomes input to the next).
   • Example filter:
     • grep database (matches lines containing the word/phrase)
   • Lesson: focus on relevant errors using filtering.

7. Save filtered results to a new file

   • Redirect output into a file:
     • > database errors.txt
   • Validate it exists and isn’t empty:
     • ls -l
     • cat database errors.txt

D) Copy saved troubleshooting artifacts for persistence

• Copy using:
  • cp <source> <destination>
• Example goal:
  • Backup database errors.txt to /root with a shorter name (e.g., DB errors.txt).

E) Count occurrences of a specific failure

1. Filter for a multi-word phrase (requires quotes)

   • grep "connection refused" on the saved error file.

2. Count matching lines

   • Pipe into:
     • wc -l

• Lesson:
  • Use filtering + counting to understand frequency and retries.

F) Find database configuration files across the entire system

• Locate likely config files using:
  • find ...
• Approach shown:
  • Search for files matching a pattern/substring (related to configs containing dokon / “docon” in subtitles).
  • Search across the whole filesystem:
    • Start from / (root of filesystem tree).
• After getting candidate files:
  • Filter again using grep to find the right ones (e.g., those containing “DB”).
• Then:
  • Enter the suspicious application folder if needed to inspect configs.

G) Compare configuration and identify the wrong port

• Compare two files using:
  • diff <file1> <file2>
• Goal:
  • Determine what changed between an active config file and a backup.
• Lesson:
  • A port mismatch causes failure:
    • The application tries connecting to 5433 instead of PostgreSQL default 5432.

H) Verify whether the correct database port is reachable

• Use curl to probe the service/port:
  • curl -I http://localhost:5432
• Purpose:
  • Check if PostgreSQL responds on port 5432 (headers only, not full content).
• Outcome:
  • Confirms the database is running on the expected port, so the application config is wrong.

I) Fix the configuration using an editor (Vim)

1. Open the config file in Vim:
   • vim <configfile>
2. Handle Vim modes:
   • Press i to enter insert/edit mode.
3. If prompted about read-only:
   • File permissions are likely preventing edits.
4. Exit without saving:
   • Esc then :q!
5. Save after changes:
   • Esc then :wq

J) Resolve read-only / permission issues by changing file permissions

• Inspect permissions with:
  • ls -l

• Key concept:

  • Permission bits govern read/write/execute for:
    • owner, group, others

• Change permissions using:

  • chmod <mode> <file>

• Mode examples discussed:

  • 444 = read-only for all
  • 666 = read/write for all
  • 777 = full read/write/execute for all
  • 0 = no permissions

• Goal in the demo:

  • Modify permissions so the config file becomes editable, edit it, then revert it back to read-only.

K) Restart the application (implied)

• After updating the corrected port in the config:
  • Restart so the application uses the new configuration.
• Expected result:
  • The application connects to PostgreSQL on the correct port.

L) Exit the container

• Command:
  • exit
• Outcome:
  • Returns to the host OS terminal.
• Verification:
  • Run uname again to confirm you’re back on the host OS (Darwin-based system in subtitles).

---

Speakers or sources featured (as identifiable from subtitles)

• Video creator / instructor (unnamed speaker; demonstrates commands and explains steps)
• Docker image creator (referenced as “my custom Docker image” with a link to it)
• PostgreSQL (referenced as the database service/technology being tested)