IT Support Knowledge Base

← All runbooksLinux

Basic Linux Commands for Support

The small set of Linux commands a help desk technician uses to look around a system, check health and find problems safely.

Debian/Ubuntu-style Linux (notes for Fedora/RHEL-style where commands differ)about 4 min read

Symptoms

This runbook is a reference rather than a fix. Use it when:

  • A ticket involves a Linux workstation or server and you need to see what is going on.
  • You need to check disk, memory, network or a service quickly.
  • You're practising for a Linux home lab or a certification.

Before you start

  • Read before you change. Most commands below only show information. Be careful with anything using sudo, rm, chmod, chown, or that restarts services.
  • Never run a command you don't understand on someone else's system. Use man <command> or <command> --help first.
  • On production systems follow change-control rules and ask before restarting services.

Steps

1. Where am I, and what is here?

Command What it does
pwd Show the current folder
ls -la List files, including hidden ones, with permissions and sizes
cd /var/log Move to a folder (cd .. goes up, cd ~ goes home)
whoami / id Which user am I, and which groups am I in
cat /etc/os-release Which Linux distribution and version
uname -a Kernel version and architecture

2. Reading files and logs

Command What it does
less file.txt Scroll through a file (q to quit, /word to search)
head -n 20 file / tail -n 20 file First / last 20 lines
tail -f /var/log/syslog Follow a log live (Ctrl+C to stop). On some systems the file is /var/log/messages
grep -i "error" file Find lines containing "error", ignoring case
journalctl -u ssh --since "1 hour ago" Logs for one service (use the service name, e.g. ssh or sshd)
journalctl -p err -b Error-level messages since the last boot

3. Health: disk, memory, CPU, processes

Command What it does
df -h Free space per disk/partition (human-readable)
du -sh * Size of each item in the current folder
free -h Memory and swap use
top (or htop if installed) Live processes by CPU/memory (q to quit)
ps aux \| grep firefox Find a process by name
uptime How long since boot, and load average

4. Services

Command What it does
systemctl status nginx Is the service running, and its last log lines
sudo systemctl restart nginx Restart a service (ask first on shared systems)
systemctl list-units --failed Show services that failed

5. Network

Command What it does
ip a Network interfaces and IP addresses
ip route Default gateway and routes
ping -c 4 8.8.8.8 Test connectivity (4 packets)
ss -tulpn Listening ports and which program owns them
nslookup example.com or dig example.com Check DNS (install dnsutils if missing)
nmcli device status Network devices (on systems with NetworkManager)

6. Users, permissions, packages

Command What it does
ls -l file Show permissions, e.g. -rw-r--r-- user group
sudo chmod 640 file Change who can read/write a file (careful!)
sudo chown user:group file Change a file's owner (careful!)
sudo apt update && sudo apt upgrade Refresh package list, then install updates (Debian/Ubuntu)
sudo dnf upgrade The equivalent on Fedora/RHEL-style systems
sudo passwd username Set a user's password

7. Safe habits

  • rm has no recycle bin. Use ls with the same pattern first to see what will be removed. Avoid rm -rf unless you are certain, and never with a variable you haven't checked.
  • Press Tab to auto-complete names; use the up arrow to repeat commands; history shows past ones.
  • Copy before editing a config file: sudo cp file file.bak.
  • Keep a record of every change you make in the ticket.

8. Home-lab practice ideas

Install a Linux VM (for example Ubuntu in VirtualBox) and practise: find the five largest folders with du, break and fix a service you installed, write a note of what you ran, then check the logs to see what happened. Practising on your own VM is the safest way to get comfortable.

Escalate when

  • You'd need sudo and aren't sure of the effect, especially on a production server.
  • A disk is almost full on a server, a service is failing repeatedly, or logs show hardware errors (disk or memory).
  • You see signs of a break-in (unknown users, unexpected listening ports, strange logins in last or journalctl).

Ticket note template

Issue: <Linux symptom> on <hostname / distro + version>
Commands run (read-only unless stated): 
  df -h -> 
  free -h -> 
  systemctl status <service> -> 
  journalctl -u <service> (last errors) -> 
Changes made (with sudo): <command> at <time>  / none
Backup of any edited file: <path>
Result: Fixed / Not fixed
Next step / escalated to:

View as Markdown

How to use this

  1. Search first. Type what the user is describing, like printer offline or locked out. The search reads the whole text of every runbook, not only the titles.
  2. Narrow it down if you want to. The topic links under the search box (Windows, Network, Accounts and so on) trim the list. Click one again, or pick All, to go back.
  3. Open a runbook and read down the page. Symptoms tell you if you are in the right place. Before you start lists the quick questions. Then work through Steps in order, simplest first.
  4. Know when to stop. The shaded Escalate when box lists the signs that it is time to hand the ticket on. If any one of them matches, stop and escalate.
  5. Copy the ticket note. The last section has a note template. Press Copy, paste it into your ticketing system, and fill in the blanks.
Words you will see
Runbook
A written set of steps for one kind of problem, so you do not have to work it out from scratch each time.
First-line support
The first person a user talks to. Fixes the common problems and passes the rest on.
Escalate
Hand a ticket to someone with more access or experience, with notes so they do not have to start over.
Scope
How many people or devices are affected. One laptop and the whole office are very different problems.
Ticket note
A short written record of what was reported, what you tried and what happened.

Why I built this

I'm a computer science student in Toronto and I'm looking for junior IT support and help desk roles. When I started practising troubleshooting, I noticed I knew a lot of individual fixes but not a calm order to try them in, or when to stop and hand a problem on.

So I wrote these twelve runbooks to put that in order for myself, and I built this site so they are easy to search and read. They come from public vendor documentation and common help desk practice. They are not copied from a workplace and they are not real tickets.

They are still a work in progress. If a step looks wrong or something is missing, I would like to know.