DEV Community: Snigdha Chaudhari

Learning Linux? Don't Start by Memorising Commands

Snigdha Chaudhari — Sun, 09 Aug 2026 09:19:53 +0000

When I first started learning Linux, I thought I needed to remember a lot of commands.

ps, top, systemctl, journalctl, chmod, chown, grep, find...

The list kept growing.

But knowing what a command does is not always the same as knowing when to use it.

I could read that journalctl shows logs, but that didn't automatically tell me why I should check logs when a service fails. I knew chmod changes permissions, but that made much more sense once I actually saw a script return Permission denied.

What helped was connecting the commands to the things happening on the system.

A process is running. A service manages it. Logs help explain what happened. Files and configuration live in different parts of the filesystem. Permissions and ownership decide who can access them.

Once those pieces started connecting, the commands stopped feeling like random things I had to memorise.

So if you're learning Linux too, these are the things worth understanding first.

First, understand what's happening underneath

You don't need to go extremely deep into Linux internals at the beginning. But understanding a few basic pieces makes everything else easier.

A simplified view looks like this:

Applications
     ↓
Shell
     ↓
Kernel
     ↓
Hardware

The hardware is the physical machine: CPU, memory, storage and network interfaces.

The kernel is the core of Linux. It handles things like:

Processes
Memory
File systems
Communication with hardware

The shell is where you interact with the system using commands.

When you run:

ls

the shell interprets your command and asks the operating system to perform the required action.

So a simple way to think about it is:

You → Shell → Linux

That is already more useful than just memorising what ls does.

A program running is a process

A process is simply a program that is currently running.

Each process has a unique Process ID, or PID.

To see running processes:

ps aux

This is useful when you want to answer:

What's running on this machine?

If the system feels slow, you probably want to know which process is using resources.

For that:

top

top gives you a live view of processes along with CPU and memory usage.

To find a specific process:

ps aux | grep nginx

And if you already know the PID and want more details:

ps -p <PID> -o pid,ppid,command

This can help you see:

The process ID
Its parent process
The command used to start it

If a process needs to be stopped:

kill <PID>

And if it refuses to stop:

kill -9 <PID>

But force-stopping a process should not be the first thing you do. First understand what the process is and why it's running.

A service is not quite the same thing as a process

This was one of the concepts that helped things connect.

A process is something currently running.

A service is a program that the operating system manages.

For example, Nginx runs as one or more processes, but you usually manage it as a service.

On Linux systems using systemd, that means you can check its status:

systemctl status nginx

Start it:

sudo systemctl start nginx

Restart it:

sudo systemctl restart nginx

Enable it to start automatically after a reboot:

sudo systemctl enable nginx

And check whether it is enabled:

systemctl is-enabled nginx

The difference between these two is worth remembering:

start  → start the service now
enable → start the service automatically during boot

So if a web server isn't working, systemctl status nginx is often a much better starting point than randomly trying commands.

If something breaks, check what happened

This is where logs come in.

A service might fail because of:

A bad configuration
Missing files
Port conflicts
Permission issues
Dependency problems

Instead of guessing, check the logs.

For a service managed by systemd:

journalctl -u nginx

To see the latest entries:

journalctl -u nginx -n 50

To watch logs live:

journalctl -u nginx -f

Or to check recent activity:

journalctl -u nginx --since "10 min ago"

For normal log files:

tail -f /var/log/app.log

The important thing isn't memorising all the journalctl options.

It's remembering:

Service has a problem? Check its status. Then check its logs.

That simple flow already covers a lot of basic troubleshooting.

Know where to look

Linux has a standard filesystem structure, and knowing a few important locations can save you a lot of time.

Everything starts from:

Some directories you'll run into often are:

/home      → User home directories
/root      → Root user's home directory
/etc       → System and application configuration
/var/log   → Logs
/tmp       → Temporary files
/bin       → Essential commands
/usr/bin   → Common system commands and utilities
/opt       → Optional or third-party software

You don't need to memorise the entire filesystem hierarchy.

But knowing that:

configuration is often in /etc
logs are often in /var/log
user files are usually under /home

gives you a much better starting point when investigating something.

To see where you currently are:

pwd

To move around:

cd /var/log

To move back one directory:

cd ..

To list files:

ls

For more details:

ls -l

And to include hidden files:

ls -la

Disk full? Don't guess—find out what's using it

A server running out of disk space is a common problem.

First, check the available disk space:

df -h

If you need to see how much space files or directories are using:

du -sh *

And if you suspect logs are growing:

du -sh /var/log/* 2>/dev/null | sort -h | tail -5

This checks the sizes of entries inside /var/log, sorts them, and shows the largest ones.

Again, the command is easier to remember when you connect it to the question:

What's using my disk space?

Files: create them, read them, change them

Creating a file:

touch notes.txt

Creating a directory:

mkdir projects

Creating nested directories:

mkdir -p project/app/logs

To read a file:

cat notes.txt

For a large file:

less notes.txt

To see the first few lines:

head -n 5 notes.txt

To see the last few:

tail -n 5 notes.txt

One small thing that is easy to forget:

echo "Hello" > notes.txt

> writes to the file by replacing its existing content.

But:

echo "Hello" >> notes.txt

adds the content to the end.

A simple reminder:

>   = overwrite
>>  = append

You can also use:

echo "Hello" | tee -a notes.txt

This writes to the file while also showing the output on the screen.

Permissions explain a lot of "Permission denied" errors

Linux permissions are based on three things:

r → read
w → write
x → execute

These permissions are applied to:

Owner | Group | Others

You can check them using:

ls -l

For example:

-rwxr-xr-x

can be read as:

Owner   → rwx
Group   → r-x
Others  → r-x

Permissions can be changed using chmod.

To make a script executable:

chmod +x script.sh

To remove write permission:

chmod -w file.txt

You can also use numeric permissions.

The values are:

read    = 4
write   = 2
execute = 1

So:

chmod 755 script.sh

means:

7 → read + write + execute
5 → read + execute
5 → read + execute

This becomes easier to understand when you actually see the result.

A script without execute permission:

./script.sh

can return:

Permission denied

Add execute permission:

chmod +x script.sh

and it can run again.

That one error teaches more about chmod than memorising the command definition ever will.

Permissions and ownership are different

This is another important distinction.

Permissions answer:

What can people do with this file?

Ownership answers:

Who does this file belong to?

Every Linux file has an owner and a group.

You can check both using:

ls -l

For example:

-rw-rw-r-- 1 ubuntu developers file.txt

Here:

Owner → ubuntu
Group → developers

To change the owner:

sudo chown username file.txt

To change only the group:

sudo chgrp groupname file.txt

To change both:

sudo chown username:groupname file.txt

For an entire directory and everything inside it:

sudo chown -R username:groupname directory/

The -R means recursive.

The easiest way to remember these commands is:

chmod → changes permissions
chown → changes owner
chgrp → changes group

And after making changes:

ls -l

Always verify.

Don't just run commands. Verify what changed.

One thing that kept coming up while practising Linux was this:

Running a command doesn't mean the job is finished.

If you start a service:

sudo systemctl start nginx

check:

systemctl status nginx

If you change permissions:

chmod +x script.sh

check:

ls -l script.sh

If you change ownership:

sudo chown user:group file.txt

check:

ls -l file.txt

A good habit is:

Change something
      ↓
Check the result
      ↓
Test that it works

That habit is useful far beyond Linux.

The commands I would remember first

If I had to reduce everything down to a small set, I wouldn't try to remember commands alphabetically.

I'd remember them by the questions they help answer.

What's running?

ps aux
top

Is the service healthy?

systemctl status <service>

Why did the service fail?

journalctl -u <service> -n 50

What is using disk space?

df -h
du -sh *

Where am I and what's here?

pwd
ls -la

Who owns this file and what permissions does it have?

ls -l

Why can't I run this script?

ls -l script.sh
chmod +x script.sh

Where is this file?

find / -name "filename"

These aren't the only commands worth learning.

They're just a useful starting point because they answer real questions you are likely to ask.

Final thought

Linux started making more sense when I stopped treating commands like flashcards.

The command matters, but the problem behind it matters more.

Instead of trying to remember:

journalctl shows logs

I now think:

My service isn't working. What happened? Check the logs.

Instead of:

chmod changes permissions

I think:

This script says "Permission denied." Does it have execute permission?

Instead of:

du shows disk usage

I think:

The server is running out of space. What's taking it?

The commands eventually become easier to remember because you're connecting them to situations.

And I think that's a much better place to start when learning Linux.

90 Days of DevOps, Day 4-6: Turning Linux Practice Into Real Troubleshooting

Snigdha Chaudhari — Sat, 01 Aug 2026 05:56:39 +0000

Part of #90DaysOfDevOps - a 90-day challenge to build Linux and DevOps fundamentals, one small hands-on task a day. This post covers Day 4 (process & service checks), Day 5 (a troubleshooting drill), and Day 6 (basic file read/write) as one story, because they turned into one.

The setup

Day 4's task was simple on paper: run a few basic commands, check what's running, inspect one service. I started with the most basic one there is.

ps aux | head -5

Then I sorted by memory to see the bigger picture.

top -l 1 -o mem -n 8

727 processes. On a machine where I thought I had ten things open. Most of it was normal background stuff — Chrome runs a separate process per tab, so five "Chrome Helper" entries isn't strange. But two entries stood out: mysqld at 515MB, and node at 348MB, both idling, both things I hadn't opened today.

I checked what the node one actually was:

ps -p 745 -o pid,ppid,command

It was OpenClaw — one of the AI automation agent tools I'd installed myself a while back, because I genuinely like building with it. Nothing sinister. But its parent process ID was 1, meaning it hadn't been started by me clicking anything today — it had been started by launchd, the thing that boots every service on a Mac, at login.

So I checked what else was set up the same way:

ls ~/Library/LaunchAgents

Five files. Three belonged to Chrome's updater. Two were mine — OpenClaw and Hermes, another agent tool I'd set up. I'd installed both on purpose. What I hadn't clocked was that they were both registered as LaunchAgents with RunAtLoad: true — meaning launchd fires them up automatically every single time I log in, forever, whether I open them that day or not. And both had KeepAlive: true, meaning even if I killed the process by hand, launchd would just restart it. I'd never actually stopped either one — I'd just closed the terminal window I originally started them from, and they kept quietly running underneath that.

I decided I didn't want them running 24/7 anymore, so I stopped them the right way — through launchd, not with kill (which would have just triggered a restart) — removed their startup files, and uninstalled the leftover pieces, including a launcher for Hermes still sitting on my PATH pointing at a folder I'd already deleted.

One thing was still unexplained, though: mysqld.

Day 5: actually finding out why MySQL was running

Day 5's task was a proper troubleshooting drill — pick a service, check its health, read its logs, write it up as a runbook. MySQL was the obvious target.

Health-wise it was fine — 0.2% CPU, idle:

ps -o pid,pcpu,pmem,etime,comm -p $(pgrep -x mysqld)

Then I checked what was listening on its port:

lsof -i :3306

Empty. But when I actually tried connecting:

nc -vz localhost 3306

"Connection succeeded." Contradiction. Turned out lsof only shows processes you own unless you run it with sudo, and mysqld runs as a different system user. Empty didn't mean nothing was there — it meant I wasn't allowed to see it yet.

sudo lsof -i :3306

That's when I found the actual issue: it wasn't just listening on my machine, it was listening on *:3306 — every network interface, not just localhost. Same on a second port, 33060. A database on my personal laptop had been reachable from any network I connected to, not just from me.

I checked when it had even arrived:

pkgutil --pkg-info com.mysql.mysql

November 2025. Running at every boot since, and inside it, one database called employee_db — almost certainly leftover from some SQL course I'd followed along with last winter. Healthy, clean logs, nothing wrong with it — it just had no reason to still be running, and definitely no reason to be network-reachable. Backed up the data folder, then removed it the same way: stopped through launchd, registration removed, software uninstalled.

Day 6: back to basics

After two days of chasing down services, Day 6 was refreshingly small: create a text file, write into it, read it back. Three ways to put text in a file, and the difference between them turned out to matter a lot:

echo "Line 1" > notes.txt      # replace the whole file
echo "Line 2" >> notes.txt     # add to the end
echo "Line 3" | tee -a notes.txt  # add to the end AND show it on screen

Small lesson, but it's the same instinct as the last two days: read what's already there before deciding whether to overwrite it or add to it.

What actually happened this week

I went in expecting three small tasks. What I actually did was realize two tools I'd installed on purpose had quietly been running non-stop since I set them up, find an unrelated database that had been exposed to the network for eight months, and clean up all three properly instead of just force-quitting and hoping.

Biggest lesson: an empty result from a command doesn't always mean "nothing's here." lsof without sudo told me nothing was on port 3306. It was wrong — or more accurately, it just wasn't allowed to tell me. One flag fixed it.

Command reference — for future me

The commands below, grouped by what question they answer, with the Linux equivalent next to the macOS one I actually used. macOS uses launchd where Linux uses systemd — different tool, same job: start services, keep them alive, own their logs.

"What's running right now?"

What I want to know	macOS	Linux
List all processes	`ps aux`	`ps aux`
Live view, sorted by memory	`top -l 1 -o mem -n 8`	`top -b -n 1`
Find a process by name	`pgrep -l <name>`	`pgrep -l <name>`
Full detail on one PID	`ps -p <pid> -o pid,ppid,command`	same

PPID 1 means launchd/systemd started it, not a person clicking something. That's the tell for "this is an auto-starting service."

"What auto-starts, and how do I see its config?"

What I want to know	macOS	Linux
Things that start when I log in	`ls ~/Library/LaunchAgents`	user systemd units, `systemctl --user list-units`
Things that start at boot, system-wide	`ls /Library/LaunchDaemons`	`systemctl list-units --type=service`
Is this service running, and its config	`launchctl list \	grep `then read its` .plist`
System-owned services (needs sudo)	`sudo launchctl list \	grep `

Key config flags to look for in a .plist (or a systemd unit): RunAtLoad/WantedBy = starts automatically. KeepAlive/Restart= = comes back if killed. If both are set, kill will not work — you have to stop it through the supervisor.

"How do I actually stop something for good?"

Step	macOS	Linux
1. Stop it via the supervisor	`launchctl bootout gui/$(id -u) <path-to-plist>` (user) or `sudo launchctl bootout system <path>` (system-wide)	`systemctl stop <name>`
2. Stop it from coming back	`rm <path-to-plist>`	`systemctl disable <name>`
3. Remove the software	`rm -rf`, `npm uninstall -g`, or the app's uninstaller	`apt remove` / `yum remove` etc
4. Verify it's gone	`launchctl list \	grep `and` pgrep -fl ` — both should be empty

Never just kill something with KeepAlive/Restart set. Always go through the supervisor first.

"Is anything listening on a port, and who?"

What I want to know	macOS	Linux
What's listening on a port	`lsof -i :<port>`	`ss -tulpn` or `lsof -i :<port>`
See services owned by other users too	add `sudo`	usually no sudo needed
Can I actually reach it	`nc -vz localhost <port>` or `curl -I`	same

If a plain lsof/ss shows nothing but you know something's there — re-run with sudo. Empty output can mean "wrong permissions," not "nothing's here."

Also check what it's bound to: localhost / 127.0.0.1 = only reachable from this machine. * or :: = reachable from the whole network. The second one is usually a mistake on a laptop.

"Where are its logs?"

What I want to know	macOS	Linux
System-wide unified log	`log show --last 5m --predicate 'process == "<name>"'`	`journalctl -u <name> -n 50`
A specific log file	`tail -n 50 <path>`	`tail -n 50 <path>`

Not every service uses the system log — some (like MySQL) write their own log file. Check the service's own directory or its config for where it actually logs.

"Is the machine healthy?"

What I want to know	macOS	Linux
Disk space free	`df -h /`	`df -h`
What's using the disk	`du -sh <folder>`	same
Memory	`vm_stat`	`free -h`
Load average	`iostat` (bottom right) or `uptime`	`uptime`, `vmstat`

Reading and writing files — the Day 6 basics

What I want	Command	Notes
Create an empty file	`touch file.txt`	does nothing if it already exists
Write, replacing the file	`echo "text" > file.txt`	wipes anything already in the file
Write, adding to the end	`echo "text" >> file.txt`	safe, doesn't touch what's there
Write and see it at once	`echo "text" \	tee -a file.txt`
Read the whole file	`cat file.txt`
Read just the top	`head -n <N> file.txt`
Read just the end	`tail -n <N> file.txt`, or `tail -f` to watch it live	`-f` is what you use to watch a log grow

The one habit worth keeping from all three days

Snapshot before you touch anything. Interpret before you act. If something needs to stop, stop it through whatever's supervising it, never with a bare kill. And treat "no output" as a question, not an answer — check if you're even allowed to see the whole picture before you trust it.