A Practical Linux Command-Line Workflow for Everyday Server Tasks

When a server behaves oddly, the hard part is often knowing what to check first. A useful command-line workflow starts with your location, narrows down the problem, and only then changes files or services.

Here’s a small toolkit for common tasks: finding a log, searching it, checking a service, and confirming that there’s enough disk space. The commands are common across Linux systems, though some utilities and service names vary by distribution.

Start by orienting yourself

Before changing anything, confirm where you are and what’s in the directory:

pwd
ls -lah

pwd prints your current directory. ls -lah shows files—including hidden ones—in a detailed, human-readable listing. Linux paths are case-sensitive, so Config and config can refer to different names.

Move to a known location with cd, then check again:

cd /var/log
pwd
ls -lah

For a command you don’t recognize, check its manual rather than guessing at flags:

man ls

Press q to leave most manual pages. Square brackets in documentation usually mark optional parts; they aren’t something to type literally.

Find and read the relevant log

A log directory can contain many files. Use find to locate likely candidates by name:

find /var/log -type f -name "*.log" 2>/dev/null | head

This searches /var/log for regular files whose names end in .log. The redirection hides error messages such as permission warnings; it doesn’t grant access to files you can’t read. head limits the displayed results, which is useful when a search returns a long list.

For more ways to search by file name, type, size, or modification time, see this practical guide to Linux find.

Once you have a candidate file, use less to read it interactively:

less /var/log/example.log

Use the arrow keys to move and q to exit. For a quick look at the newest lines, use tail:

tail -n 30 /var/log/example.log

To search for a word such as error, use grep:

grep -in "error" /var/log/example.log

Here, -i ignores letter case and -n includes line numbers. You can also pipe output from one command into another. For example, this shows matching lines among the latest log entries:

tail -n 100 /var/log/example.log | grep -in "error"

For more pattern-matching examples, see this guide to searching files with grep.

Check a service without guessing

On a systemd-based machine, systemctl status shows whether a service is active and provides recent status details:

systemctl status nginx

Replace nginx with the service you’re investigating. If you need to inspect its logs, journalctl can filter the systemd journal by service:

sudo journalctl -u nginx --since today --no-pager

--since today limits the time range, and --no-pager prints output directly. Reading logs may require elevated privileges, so use sudo only when needed. A service name or logging setup can differ across systems.

Don’t jump straight to restarting a service. First read its status and logs to understand what failed; restarting can interrupt users and may not fix the underlying cause.

Check disk space before a deployment

A full filesystem can prevent an application from writing logs, caches, or uploaded files. Check filesystem capacity with:

df -h

To estimate the space used by a particular directory, run:

du -sh ~/projects

These commands answer different questions: df reports space available on mounted filesystems, while du estimates the space used by a directory. If the numbers seem inconsistent, they may be measuring different things.

Make changes carefully

Commands that inspect data are usually safer than commands that modify it. Before deleting or changing files, confirm the target and your current directory:

pwd
ls -lah /path/to/target

A command such as rm normally removes files without sending them to a desktop trash folder. Permission and ownership changes can also affect applications, so avoid applying broad recursive changes unless you understand exactly which files they will touch.

Use the least privilege needed. If a command genuinely requires administrator access, add sudo to that command—not to every command in your session. Before unfamiliar operations, read man command or command --help, and practice on non-production files when possible.

A short troubleshooting sequence

When investigating a server issue, this order keeps the work focused:

1. Run pwd and inspect the relevant directory with ls.
2. Locate the file or service you need to investigate.
3. Read recent output with tail, less, or journalctl.
4. Search for a specific symptom with grep.
5. Check service status and filesystem capacity.
6. Make a targeted change only after confirming its impact.

The goal isn’t to memorize every Linux command. It’s to combine a few reliable tools, verify what they’re pointing at, and understand the output before making a change.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.