Linux Commands Every Help Desk Tech Should Know

If you work help desk long enough, someone eventually hands you a Linux box and says something wildly casual like, “Can you just check the logs?”

That is usually the moment your brain opens eighteen browser tabs and quietly leaves the building.

The good news: you do not need to know every Linux command to be useful. You need a small set of commands you can reach for when a ticket says the server is slow, a service is down, disk space is gone, permissions are weird, or a user says “nothing changed” in the ancient language of lies.

This is the practical help desk list. Not a 400-command cheat sheet. Not terminal cosplay. Just the commands that help you answer the first question on most Linux support tickets:

What is happening on this machine right now?

TL;DR: the starter command list

If you only remember the short version, start here:

pwd
ls -la
cd /path/to/folder
cat file.txt
less file.txt
tail -f /var/log/syslog
df -h
du -sh *
free -h
top
ps aux
systemctl status service-name
journalctl -u service-name
ip addr
ss -tulpn
whoami
sudo command

That list covers navigation, files, logs, disk space, memory, processes, services, networking, and permissions. It is not everything, but it is enough to stop being helpless when a terminal opens.

If you are brand new, pair this with the broader Linux for IT support beginner roadmap so the commands have a place to live in your brain.

1. pwd: check where you are before you do anything weird

pwd means “print working directory.” It tells you your current location.

pwd

Example output:

/home/alex

This sounds too basic to matter. It matters constantly.

A beginner mistake is running copy, move, delete, or install commands from the wrong directory because you assumed you were somewhere else. Linux will not always stop you. Linux is not your mom.

Use this habit when you feel lost:

pwd && ls -la

That tells you where you are and what is around you.

2. ls: list files without guessing

ls shows files and folders.

ls
ls -la
ls -lh

Useful flags:

• -l shows details.
• -a includes hidden files, like .env or .ssh.
• -h makes file sizes readable, like 12K or 4.1G.

In help desk work, ls -la is one of the first commands you run when checking config directories, upload folders, log folders, home directories, and weird vendor app paths.

Example:

ls -lah /var/log

Common mistake: forgetting hidden files exist. On Linux, many important config files start with a dot, which means plain ls will hide them.

3. cd: move around without panic-clicking for Explorer

cd changes directories.

cd /var/log
cd ..
cd ~
cd -

What those mean:

• cd /var/log goes to a specific path.
• cd .. moves up one level.
• cd ~ goes to your home directory.
• cd - jumps back to the previous directory.

That last one is underrated. If you bounce between a config folder and a log folder, cd - saves you from retyping long paths like a medieval monk copying scripture.

4. cat, less, head, and tail: read files safely

A lot of Linux troubleshooting is reading text files: configs, logs, scripts, service files, and application output.

Start with these:

cat notes.txt
less /var/log/syslog
head -20 /var/log/syslog
tail -50 /var/log/syslog
tail -f /var/log/syslog

Use them like this:

• cat prints a small file.
• less opens a big file so you can scroll.
• head shows the beginning.
• tail shows the end.
• tail -f follows a log live.

Real support example: a user reports an app error, you restart the app, then watch the log while reproducing it:

tail -f /var/log/syslog

On Ubuntu servers, app logs may also live under /var/log/<app-name>/ or be managed by systemd. More on that in a minute.

Common mistake: using cat on a giant log file. Your terminal becomes a waterfall of regret. Use less or tail instead.

We also have a deeper beginner guide on using the Linux cat command if you want the slower version.

5. df and du: find disk space problems

“No space left on device” is one of the most common Linux problems you will see. It can break updates, logs, uploads, databases, backups, and basically anything that needs to write files.

Start with:

df -h

That shows disk usage by filesystem in human-readable units.

Then use du to find what is large inside a directory:

du -sh *
du -sh /var/log/*

What they mean:

• df -h answers: “Which disk or partition is full?”
• du -sh * answers: “What folders/files here are taking space?”

A safe beginner investigation flow:

df -h
cd /var/log
sudo du -sh *

Common mistake: deleting random files before you understand what is filling the disk. Logs, caches, Docker images, backups, and user uploads have different cleanup paths. Do not just rm -rf your way into a resume-generating event.

6. free and top: check memory and CPU

When someone says “the Linux server is slow,” you need a quick way to check resource pressure.

free -h
top

free -h shows memory usage. top shows running processes, CPU usage, memory usage, and load.

In top, look for:

• A process eating CPU.
• A process eating memory.
• Load average that seems high for the system.
• Zombie or runaway processes.

You can press q to quit top.

Common mistake: seeing Linux use a lot of memory and immediately panicking. Linux uses free memory for cache. That is normal. Look at available memory, swap usage, and whether users are actually experiencing symptoms.

7. ps: find running processes

ps shows process information. A common beginner-friendly version is:

ps aux

You can combine it with grep to look for something specific:

ps aux | grep nginx
ps aux | grep ssh

This helps answer questions like:

• Is the app running?
• Is the old backup process still stuck?
• Is there already a copy of this script running?

Common mistake: forgetting that grep may find itself in the results. If you run ps aux | grep nginx, you might see the grep nginx command too. That does not mean nginx is running.

A cleaner version is:

pgrep -a nginx

But ps aux | grep something is still common enough that you should understand it when you see it.

8. systemctl: check and restart services

Modern Linux distributions usually manage services with systemd. The command you use is systemctl.

Examples:

systemctl status ssh
sudo systemctl restart ssh
sudo systemctl stop nginx
sudo systemctl start nginx
sudo systemctl enable nginx

What matters for support:

• status tells you if a service is running or failed.
• restart restarts it.
• enable makes it start on boot.

Real-world ticket: a web service is down.

systemctl status nginx
sudo systemctl restart nginx
systemctl status nginx

Common mistake: restarting a service before checking status or logs. If you restart first, you might erase useful clues about what failed. Check first when possible.

Also: service names vary. It might be apache2 on Ubuntu and httpd on some Red Hat-like systems. Linux enjoys keeping you humble.

9. journalctl: read systemd logs

If systemctl status says a service failed, journalctl is often the next command.

journalctl -u nginx
journalctl -u nginx -n 50
journalctl -u nginx -f

What those do:

• journalctl -u nginx shows logs for the nginx service.
• -n 50 shows the last 50 lines.
• -f follows new log lines live.

This is huge for beginner sysadmin troubleshooting because not every useful log is sitting neatly in /var/log/app.log.

Common mistake: reading the whole journal with no filter and drowning in unrelated noise. Filter by unit with -u when you know the service name.

10. ip addr and ss: check networking basics

Networking tickets need quick facts: What IP does this machine have? Is a port listening?

Use:

ip addr
ss -tulpn

ip addr shows network interfaces and IP addresses.

ss -tulpn shows listening TCP/UDP sockets and the processes using them. You may need sudo to see process names for all services:

sudo ss -tulpn

Support examples:

ip addr
sudo ss -tulpn | grep :22
sudo ss -tulpn | grep :80
sudo ss -tulpn | grep :443

That helps answer:

• Does the server have the expected IP?
• Is SSH listening?
• Is the web server listening on port 80 or 443?
• Is some other process already using the port?

Common mistake: confusing “service installed” with “service listening.” A package can be installed and still not be running or accepting connections.

There is also a practical guide on finding your IP address on Linux if networking commands are still foggy.

11. whoami, id, and sudo: understand who you are

Permissions problems get less mysterious when you know what user you are acting as.

whoami
id
sudo command

whoami prints your current username. id shows your user ID and groups. sudo runs a command with elevated privileges if your account is allowed.

Example:

whoami
id
sudo systemctl status ssh

Common mistake: assuming every “permission denied” means you should slap sudo on it. Sometimes the file ownership is wrong. Sometimes you are in the wrong directory. Sometimes the command is trying to write somewhere it should not. sudo is a tool, not hot sauce.

A simple help desk troubleshooting flow

When you SSH into a Linux machine and do not know where to start, use a boring checklist:

pwd
whoami
hostname
ip addr
df -h
free -h
systemctl status service-name
journalctl -u service-name -n 50

Then adjust based on the ticket.

If it is a disk issue, use du.

If it is a service issue, use systemctl and journalctl.

If it is a network issue, use ip addr, ss, and maybe ping or curl.

If it is a file issue, use ls -la, less, and permissions checks.

The secret is not memorizing every flag. The secret is knowing which question each command answers.

Practice without breaking production

Reading a command is fine. Running it in a safe environment is where it actually sticks.

That is exactly why Shell Samurai exists: you can practice beginner Linux tasks in a safe terminal without turning a real server into a campfire.

Practice these Linux commands in Shell Samurai and get comfortable before the ticket queue makes it personal.

Final thought

You do not become useful with Linux by reading a giant cheat sheet once. You become useful by practicing small loops:

1. Where am I?
2. What is running?
3. What changed?
4. What do the logs say?
5. What is full, broken, stopped, or misconfigured?

Learn the commands in this post and you will be able to handle a surprising amount of beginner Linux support work without panic-Googling every ticket.

Still Google things. Everyone does. Just do it from a place of slightly less terror.