Article Details

Azure Overseas Account Essential Linux Commands for Azure VM Users

Azure Account2026-05-20 13:59:35MaxCloud

Welcome to the Azure VM Command Zone

So you’ve got an Azure VM and you’re using Linux. Great. You’re in the part of the universe where you can either (a) click through a UI, or (b) type commands into a terminal like a wizard with a keyboard. In Azure, the terminal is often the quickest path to clarity, especially when the VM is doing something mysterious, slow, or downright moody.

This article is a curated set of essential Linux commands that Azure VM users actually use. Not the “cool but rarely helpful” stuff. Not the “read-only once you’ve already fixed it” trivia. Instead, think of this as your command toolbox: navigation, file wrangling, system health checks, process management, networking, disk space, package installation, permissions, and logs. You’ll also see a few “common traps” that make beginners swear at the screen, then apologize to it five minutes later.

Let’s assume you’re comfortable with the basics (you can open a terminal and you know what a prompt is). If you’re not, don’t worry: these commands come with context and practical examples.

1) Getting Oriented: The Terminal Basics That Save Your Life

Know where you are: pwd

When you feel lost, use the classic:

pwd

Example: You’re trying to find a file and you swear it’s “right there.” Check your current directory. Linux is very literal. “Right there” in your brain might be “left there” in the filesystem.

Move around: ls

To list files and directories:

ls

Helpful variations:

ls -la

This shows hidden files (those starting with a dot) and includes permissions, owner, group, size, and modification times. Azure VMs often come with “hidden” configuration files, and you’ll want to see them when debugging.

To list recursively (use carefully if the directory is huge):

ls -R

Navigate directories: cd

Use cd to change directories:

cd /var/log

Tip: if you’re not sure, use absolute paths like /var/log rather than relying on your current directory. Your future self will thank you.

Quick shortcuts:

cd ~

Goes to your home directory.

Azure Overseas Account cd -

Returns to the previous directory. It’s like an “undo” for navigation.

View file contents: cat, less, head, tail

In Azure VM land, logs are your best friends and your worst enemies. Knowing how to read files efficiently matters.

cat file.txt

Dumps the whole file to your terminal. Great for tiny files. Terrible for big log files. Unless you enjoy scrolling until your coffee cools.

less file.txt

Paginated view with search and navigation. This is the adult option.

head -n 50 /path/to/file

Shows the first lines.

tail -n 50 /path/to/file

Shows the last lines.

To follow a log as it updates:

tail -f /var/log/syslog

Azure Overseas Account On many systems, system logs may live in /var/log/syslog, /var/log/messages, or in journal-based logging. More on that later.

2) Find What You Need: Searching Without Losing Your Mind

Locate files fast: find

When you can’t remember where something is, use find. It’s powerful, and it can also be powerful in the “oops that’s scanning the entire disk” way.

Example: find a file by name within /var:

find /var -name "nginx.conf" 2>/dev/null

The 2>/dev/null part suppresses permission errors. Without it, find may complain about directories you don’t have access to, like a petulant butler.

Example: find recently modified files:

find /var/log -type f -mtime -7

This shows files modified within the last 7 days.

Search inside files: grep

grep searches for text within files. It’s the “needle in the haystack” command, except sometimes you’re the haystack.

Search for a keyword in a log file:

grep "error" /var/log/syslog

More useful: show line numbers and context:

grep -n "failed" /var/log/syslog

Show 3 lines before and after each match:

Azure Overseas Account grep -n -C 3 "timeout" /var/log/syslog

If you want to search through multiple files:

grep -R "Client disconnected" /var/log 2>/dev/null

Again, 2>/dev/null helps avoid a spamfest of permission errors.

3) Manage Files and Folders Like a Responsible Adult

Copy, move, rename: cp, mv

Copy a file:

cp source.txt destination.txt

Copy recursively (directories):

cp -r /path/to/folder /new/location

Move or rename:

mv oldname newname

Pro tip: mv is also how you effectively rename files. There’s no “rename” command because Linux likes to keep things efficient and confusing.

Create directories: mkdir

mkdir -p creates parent directories as needed:

mkdir -p /opt/myapp/logs

Remove files carefully: rm

Remove a file:

rm file.txt

Remove a directory:

rm -r folder

Safer option: interactive mode prompts before deleting:

rm -i file.txt

When you’re debugging on a production-like VM, -i is a calming voice in the chaos.

View disk usage: du

Ever wondered what’s eating your disk? du tells you.

Example:

du -sh /var/log

-s = summarized, -h = human-readable.

See sizes by subdirectory:

du -h /var/log --max-depth=1

4) Permissions and Ownership: The “Why Can’t I Read That?” Toolkit

Check permissions: ls -l

Use:

ls -l

You’ll see a permission string like drwxr-xr-x. That determines who can read, write, and execute.

Change permissions: chmod

chmod changes file mode/permissions.

Example: make a script executable:

chmod +x script.sh

Example: set permissions numerically:

chmod 644 file.conf

Azure Overseas Account That means: owner can read/write, group and others can read.

For directories, the rules get more interesting, but the takeaway is: chmod is how you fix access problems without assuming the OS is “just broken.” It’s rarely broken. It’s usually just not permissioned for your current user.

Change ownership: chown

chown changes who owns the file.

Example:

sudo chown ubuntu:ubuntu /var/www/html/index.html

Use sudo because ownership changes are privileged actions.

See user identity: whoami and id

whoami prints your username:

whoami

id prints user and group IDs:

id

These are handy when you think you’re “root-ish” but actually you’re not. Linux can be humbling that way.

Azure Overseas Account 5) System Health Checks: The Commands That Tell You What’s Going On

Uptime: uptime

To see how long the system has been running:

uptime

Azure Overseas Account It shows current time, uptime duration, and load averages. If load averages look scary, you know something is straining.

CPU and memory: top, htop, free, vmstat

Basic live view:

top

It updates continuously, showing processes consuming resources.

If you install it, htop is like top’s friendlier cousin:

Azure Overseas Account htop

To see memory usage:

free -h

This prints memory in human-readable format.

To get a broader performance snapshot:

vmstat 1

vmstat 1 updates every second, so you can watch CPU, memory, and I/O patterns in real time.

Disk space: df

df -h shows filesystem disk usage:

df -h

To see inode usage too (sometimes files are “gone” but inodes are still used):

df -ih

It’s rare, but when it happens, you’ll be glad you checked.

Network usage: ip, ss, ping, curl

Azure networking is a whole topic by itself, but these commands are your “basic triage kit.”

See IP addresses and interfaces:

Azure Overseas Account ip a

Show routing table:

ip route

Check listening ports and sockets:

ss -ltn

-l = listening, -t = TCP, -n = numeric ports (no DNS lookups).

Test connectivity:

ping -c 4 8.8.8.8

curl is useful for HTTP endpoints:

curl -I http://localhost:8080

-I fetches headers only, which is often enough to confirm the service is alive.

Azure Overseas Account 6) Processes and Services: Controlling the Running World

List processes: ps

Basic process listing:

ps aux

To filter:

ps aux | grep nginx

The pipe does what it says: it sends output from ps into grep.

Search and manage processes: pgrep and pkill

pgrep finds process IDs by name or pattern:

pgrep -fl nginx

pkill stops processes by name:

pkill nginx

Use these carefully. If you’re not sure, check with pgrep first.

Stop, start, and check services: systemctl

Most modern Linux distributions use systemd. systemctl manages services.

To check service status:

sudo systemctl status nginx

To start:

sudo systemctl start nginx

To stop:

sudo systemctl stop nginx

To restart:

sudo systemctl restart nginx

To enable at boot:

sudo systemctl enable nginx

Common debugging workflow: if a service fails, check status, then check logs (we’ll do logs next), then try restart.

7) Logs and Troubleshooting: Where the Truth Lives

Systemd journal: journalctl

If your system uses systemd, journalctl is extremely useful.

Show recent logs:

journalctl -n 100

Show logs for a specific service:

journalctl -u nginx --since "1 hour ago"

Follow logs in real time:

journalctl -u nginx -f

This is often more convenient than hunting across many files in /var/log.

Common log locations

Depending on distro, you’ll often find logs in:

  • /var/log/syslog (Debian/Ubuntu often)
  • /var/log/messages (some RHEL-like systems)
  • /var/log/auth.log or /var/log/secure (authentication-related)
  • /var/log/nginx/ and /var/log/apache2/ (web server logs)
  • /var/log/mysql/ or /var/log/postgresql/ (database logs)

When in doubt, list what exists:

ls /var/log

Then pick the relevant file(s) and use tail -f.

Watch a file grow: tail -f

For quick “what’s happening right now” checks:

tail -f /var/log/auth.log

If you’re troubleshooting SSH/login issues, auth logs are usually a good place to look.

Azure Overseas Account Validate configuration: nginx -t (example)

Many services provide a config test command. For Nginx:

sudo nginx -t

It checks syntax and configuration. If it fails, don’t restart the service yet—fix the config first. Otherwise you’ll just get to enjoy failing twice.

8) Package Installation and Updates: Getting Software Without Chaos

Know your package manager: apt or yum/dnf

Different distros use different package managers. On Ubuntu/Debian systems, you’ll typically use apt. On many RHEL-like systems, you’ll use yum or dnf.

To update package lists (Ubuntu/Debian):

sudo apt update

To install a package:

sudo apt install htop

To update and upgrade installed packages:

sudo apt upgrade -y

On RHEL/CentOS/Fedora-like systems (dnf):

sudo dnf install htop

To list enabled repositories, if needed:

dnf repolist

Basic sanity checks: which and --version

To see if a command exists:

which python3

To see versions:

python3 --version

curl --version

These are useful when you’re trying to confirm what you installed or which binary your PATH is pointing to.

Azure Overseas Account 9) SSH on Azure VMs: Access Without Tears

Check SSH connectivity: ssh

From your local machine (or another host), connect:

ssh username@your-vm-ip

If you need a specific key file:

ssh -i ~/.ssh/mykey.pem username@your-vm-ip

On the VM side, you’ll want to confirm the SSH service is running:

sudo systemctl status ssh

Service names can vary (ssh vs sshd). If ssh fails, try:

Azure Overseas Account sudo systemctl status sshd

Check open SSH ports: ss

Confirm port 22 (or your configured SSH port):

sudo ss -ltnp | grep :22

-p shows process info (may require sudo). If you see nothing listening, you’ve got a service or firewall issue.

10) Firewall and Ports: Don’t Assume the VM Can Talk

In Azure, networking includes both host-level and platform-level controls. On the VM, you might have firewalld or ufw (or nothing). You should also consider Azure Network Security Groups, but those are beyond pure Linux commands. Still, these commands help you figure out what the VM itself is allowing.

ufw (Uncomplicated Firewall)

Check status:

sudo ufw status verbose

Allow a port (example 80):

sudo ufw allow 80/tcp

Enable ufw:

sudo ufw enable

Disable ufw (use carefully):

sudo ufw disable

firewalld

Check status:

Azure Overseas Account sudo systemctl status firewalld

List rules:

sudo firewall-cmd --list-all

Open a port:

sudo firewall-cmd --permanent --add-port=8080/tcp

Reload:

sudo firewall-cmd --reload

11) Environment and Basics of Shell Behavior

Check environment variables: env

To view environment variables:

env

To check a specific variable:

Azure Overseas Account echo $PATH

echo $HOME

Sometimes problems are just incorrect paths. Or missing variables. Or variables that exist in your interactive shell but not in the systemd service environment. Linux loves making that kind of thing feel like a prank.

Set and use variables: export

Temporarily set an environment variable for the current session:

export MYAPP_ENV=production

To reference it:

echo $MYAPP_ENV

For system-wide or service-level environment variables, you’ll handle that through configuration files or systemd unit settings.

See command history: history

Show command history:

history

To search history for something you ran earlier:

history | grep apt

12) Users, Groups, and Authentication: The Social Network of Linux

Who is logged in: who

See active sessions:

who

Or:

w

The w command provides additional details, including what users are doing and load averages.

Add users and permissions (basic examples)

Creating users and managing groups usually requires sudo and careful planning. But for completeness, here’s the general shape:

Create user:

sudo adduser newuser

Or on some distros:

sudo useradd -m newuser

Add user to a group:

sudo usermod -aG sudo newuser

This adds the user to the sudo group (on many Debian/Ubuntu systems). On other distros, the group name might differ.

13) Useful “It’s Not Working” Debug Commands

Let’s talk about the moments you’ll hit repeatedly on Azure VMs: a service fails, you can’t connect, DNS looks wrong, the disk is full, or memory usage spikes. These commands help you triage quickly.

Check listening ports for your service

If your app should be listening on port 3000, 8080, or 80, verify:

sudo ss -ltnp | grep :8080

If you don’t see it, the service may not be running or it’s binding to a different interface (like 127.0.0.1 instead of 0.0.0.0). That’s a classic “it works locally, why not externally?” scenario.

Confirm service status

For systemd services:

sudo systemctl status your-service-name

Then check logs:

journalctl -u your-service-name --since "15 min ago"

Check resource constraints

If your service is crashing or acting sluggish, check CPU/memory and disk space:

top

free -h

df -h

Then look for the likely culprit. If disk is full, logs might stop writing and things get even weirder.

Check DNS and connectivity (when networking feels haunted)

Test basic reachability:

ping -c 4 google.com

Test HTTP/HTTPS reachability:

curl -I https://example.com

If DNS fails, you might see errors like “could not resolve host.” In that case, check /etc/resolv.conf:

cat /etc/resolv.conf

But be cautious: Azure’s networking and DHCP can manage DNS for you, so manual changes might be overwritten.

14) A Practical Command Checklist (Because You’ll Forget Under Pressure)

Here’s a short list of “most used in the real world” commands for Azure VM Linux users. Keep it as your mental sticky note.

  • Navigation: pwd, ls -la, cd
  • Reading files: less, head, tail -n, tail -f
  • Searching: grep, find
  • Files: cp, mv, mkdir -p, rm (prefer rm -i at first)
  • Disk: df -h, du -sh
  • CPU/Memory: top, free -h
  • Processes: ps aux, pgrep -fl
  • Services: systemctl status/start/stop/restart, systemctl enable
  • Logs: journalctl -u ... and tail -f /var/log/...
  • Networking: ip a, ip route, ss -ltnp, ping, curl
  • Packages: apt update/install/upgrade (or dnf/yum equivalents)
  • Permissions: ls -l, chmod, chown, sudo

If you know these and understand what their output means, you’re already ahead of many “I followed a tutorial once” folks.

15) Safety Notes: How Not to Turn Your VM Into a Very Expensive Bonfire

Linux gives you power, and power comes with the occasional urge to do something irreversible. Here are some practical safety habits that will save you from classic disasters:

  • Use sudo deliberately. If you’re unsure, check the command first without sudo or read the help (man).
  • Prefer checking before deleting: use ls to verify paths, and consider rm -i.
  • When changing configuration files, make backups:

Example:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

  • When restarting services, run config tests first (when available). For Nginx: nginx -t.
  • When scanning logs, start with tail or journalctl --since rather than grep the entire world.

16) A Few Command Examples That Feel Like Real Work

Let’s tie it together with realistic mini-scenarios. These aren’t the only ways to do it, but they reflect how you’ll naturally use commands on an Azure VM.

Scenario A: Your web app stopped responding

1) Check the service status:

sudo systemctl status nginx

2) If it’s failing, look at recent logs:

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

Azure Overseas Account 3) Check whether Nginx is listening:

sudo ss -ltnp | grep :80

4) If config is suspected:

sudo nginx -t

5) If all looks good, restart:

sudo systemctl restart nginx

Scenario B: Disk is full and everything is weird

1) See disk usage:

df -h

2) Find big directories:

sudo du -h /var/log --max-depth=1 | sort -h

3) Inspect the largest log:

sudo tail -n 50 /var/log/syslog

4) Potential fix depends on what you find: rotate logs, truncate, or clean up old artifacts.

Scenario C: SSH connections fail

1) Confirm SSH service:

sudo systemctl status ssh

2) Confirm the port is listening:

sudo ss -ltnp | grep :22

3) Check auth logs for errors:

sudo tail -n 200 /var/log/auth.log

or:

sudo journalctl -u ssh --since "1 hour ago"

4) If you’re using a custom port, verify your security rules and configuration.

17) Closing Thoughts: Your Terminal Is a Map, Not a Mystery Box

Linux on an Azure VM can feel intimidating at first, but it’s mostly just a collection of tools that reveal truth quickly: what’s running, what’s listening, what’s consuming resources, and what the logs say happened right before things went sideways.

If you only take one thing from this article, let it be this: learn the “check status, check logs, check resources, check network” loop. It’s the fastest route from confusion to clarity. And if you get stuck, you can usually find your answer by combining a couple of commands rather than trying to summon the solution from pure willpower.

Now go forth and command your Azure VM like the competent human (or mildly caffeinated wizard) you are. May your logs be readable, your disk be spacious, and your services stay politely alive.

TelegramContact Us
CS ID
@cloudcup
TelegramSupport
CS ID
@yanhuacloud