🎯 Goal

Reinforce general Linux fundamentals with a practical focus on:

  • shell workflows
  • filesystem operations
  • shutdown troubleshooting
  • keeping technical progress aligned with the broader cybersecurity plan

The goal was to improve command-line control without drifting into random rabbit holes.

✅ What I Did

Set a focused 14-day tools lane

I defined a small parallel track to support the broader cybersecurity plan:

  • daily short Bash and CLI drills
  • two PowerShell sessions per week
  • two Python sessions per week
  • small integration tasks built around log triage and workflow thinking

This gave structure without replacing the main plan.

Started Effective Shell as the re-study source

I selected a high-value reading and practice order:

  • getting help (man, shell help)
  • pipelines and redirection
  • find
  • grep and regex extraction
  • shell expansion and globbing

This created a practical review path instead of random revisiting.

Investigated an Ubuntu shutdown delay

I noted that an approximately 90-second shutdown delay strongly suggests systemd waiting for a service stop timeout.

I mapped out the next-step checks:

journalctl -b -1 | grep -iE "timed out|stop job|A stop job|failed to stop"
journalctl -b -1 -p warning..alert
systemd-analyze blame | head -n 30

This shifted the problem from “it hangs” to a concrete diagnosis path.

Reviewed hidden files and safe deletion habits

For hidden files:

  • GUI toggle in Nautilus: Ctrl+H
  • CLI view:
ls -la

For safer directory removal, I reviewed the safety ladder:

  • empty directory:
rmdir /path/to/dir
  • recursive with prompts:
rm -rI /path/to/dir
rm -ri /path/to/dir
  • recoverable removal to trash:
gio trash /path/to/dir
  • dangerous option to avoid unless absolutely certain:
rm -rf /path/to/dir

🔗 Key Cybersecurity Connections

Pipelines and redirection build log-triage muscle

Investigations often follow this pattern:

  • filter
  • extract
  • aggregate
  • preserve evidence

Shell fluency directly supports that workflow.

systemd and journalctl provide operational visibility

If I cannot read service failures and stop timeouts, I will be blind during outages, misconfigurations, or suspicious activity.

Hidden files matter

Interesting artifacts often live in places like:

  • .ssh
  • .config
  • shell histories

These locations can contain credentials, persistence traces, or evidence of user behavior.

Safe deletion matters

Using reckless deletion commands is a self-inflicted incident waiting to happen.

⚠️ Challenges

  • translating “shutdown feels slow” into a concrete systemd diagnosis path
  • balancing speed with safe command habits
  • avoiding unnecessary detours while still building practical skill

🧠 What I Learned

  • a ~90-second shutdown delay often points to a service stop timeout
  • the fastest way to investigate is through the previous boot journal
  • filesystem operations should follow a safety ladder by default
  • better CLI habits reduce risk and increase confidence

⏭️ Next Steps

  • continue Effective Shell with deliberate practice
  • write down 3 daily commands per chapter and use them on real directories or logs
  • run the shutdown triage commands and identify the exact service causing the delay
  • build a small Bash snippet for evidence capture:
    • separate stdout and stderr
    • run a grep extraction
    • output counts and top matches

💭 Reflection

This was fundamentals-heavy work, but it directly improves real-world speed and accuracy.

Better CLI control reduces friction and prevents dumb mistakes during labs and troubleshooting.

🧩 Lessons Learned

What worked

  • adding a small tools lane instead of resetting the whole study plan

What broke

  • initial confusion around shutdown delays

Why it broke

  • I was not yet treating system behavior as something observable through logs and service state

Fix / takeaway

  • treat system behavior as evidence: inspect it, isolate it, then act on it

📈 Skill Progression Context

This day tied together shell fundamentals, filesystem safety, and basic system troubleshooting.

That supports later growth in:

  • log analysis
  • Linux investigation
  • SOC-style triage
  • automation and evidence capture