Linux basics for server management — the survival guide
Why Linux skills matter in server management
Most web hosting and server environments run Linux. Even if you use a control panel, the moment something breaks—disk fills up, a service won’t start, logs show errors—you’ll need basic Linux command-line skills to investigate quickly and safely.
This guide focuses on the “survival” set: navigating the filesystem, reading configs and logs, controlling services, checking resource usage, and testing network connectivity.
---
The Linux filesystem hierarchy (what lives where)
Linux organizes files into a single directory tree starting at `/` (root). Knowing the common directories helps you find logs, configs, and binaries without guessing.
Key directories you’ll use on servers
- `/etc` — System and application configuration files
- `/var` — Variable data that changes often
- `/home` — User home directories (e.g., `/home/alice`)
- `/root` — Home directory for the root user (admin)
- `/usr/bin` and `/bin` — Common commands and programs
- `/sbin` and `/usr/sbin` — System/admin commands (often require elevated privileges)
- `/tmp` — Temporary files (often cleared on reboot)
- `/opt` — Optional third-party software installs
- `/proc` and `/sys` — Virtual filesystems exposing kernel/system info (don’t edit casually)
---
Navigating and inspecting files: `ls`, `cd`, `cat`
`ls` — list files
```bash ls ls -l ls -lah ```
- `-l` shows permissions, ownership, size, timestamps.
- `-a` includes hidden files (starting with `.`).
- `-h` makes sizes human-readable.
```bash cd /var/www ls -lah ```
`cd` — change directory
```bash cd /etc cd /var/log cd ~ # your home cd / # filesystem root cd .. # one directory up ```
Pro tip: if you get “Permission denied,” you may need elevated privileges (commonly via `sudo`), or you may not be allowed to access that directory.
`cat` — print a file’s content
```bash cat /etc/hostname cat /etc/nginx/nginx.conf ```
On servers, `cat` is useful for small files. For huge logs, prefer paging tools (often `less`), but if you must stick to the “survival” set, combine `cat` with filtering via `grep` (next section).
---
Searching text fast: `grep`
`grep` searches for patterns in text, making it essential for scanning configs and logs.
Common `grep` patterns
Search for “error” in a log:
```bash grep "error" /var/log/syslog ```
Case-insensitive search:
```bash grep -i "failed" /var/log/auth.log ```
Search recursively in a directory (e.g., config folder):
```bash grep -R "server_name" /etc/nginx ```
Practical example: identify why SSH logins fail:
```bash grep -i "failed password" /var/log/auth.log ```
---
Permissions and access control: `chmod` (and what to be careful about)
Linux permissions control who can read/write/execute files. You’ll frequently adjust permissions for scripts, web content, or deployed binaries.
Understanding the basics
Permissions are typically shown like:
``` -rw-r--r-- ```
- First char: `-` file, `d` directory
- Next three: owner permissions (r/w/x)
- Next three: group permissions
- Last three: others permissions
`chmod` — change permissions
Make a script executable:
```bash chmod +x deploy.sh ```
Set typical permissions for a file (read/write for owner, read for everyone else):
```bash chmod 644 config.php ```
Set typical permissions for a directory (owner can write; everyone can traverse):
```bash chmod 755 /var/www/html ```
Server safety note: Avoid `chmod 777` unless you truly understand the risk. It grants everyone full access and is a common cause of security incidents.
---
Running services: `systemctl`
Most modern server distributions use `systemd` to manage services. `systemctl` is your control panel in the terminal.
Check status, start, stop, restart
Check if nginx is running:
```bash systemctl status nginx ```
Start/stop/restart:
```bash systemctl start nginx systemctl stop nginx systemctl restart nginx ```
Enable a service at boot:
```bash systemctl enable nginx ```
Disable at boot:
```bash systemctl disable nginx ```
Practical example: after editing a config, restart the service:
```bash systemctl restart nginx systemctl status nginx ```
If it fails, status output often hints at the cause and points you to logs.
---
Logs and diagnostics: `journalctl`
On `systemd` systems, many logs are accessible via the journal.
Useful `journalctl` commands
View recent logs for a specific service:
```bash journalctl -u nginx ```
Show only the most recent entries (follow mode like “tail -f”):
```bash journalctl -u nginx -f ```
Show logs since a time:
```bash journalctl -u nginx --since "1 hour ago" ```
Practical example: nginx won’t start after a config change:
1. Check status: ```bash systemctl status nginx ``` 2. Inspect detailed logs: ```bash journalctl -u nginx --since "30 min ago" ```
Look for messages about syntax errors, missing files, port conflicts, or permission issues.
---
Resource monitoring: `top` (CPU/memory/processes)
When a server is slow, start by checking whether the CPU is saturated, memory is exhausted, or a runaway process is causing trouble.
Run:
```bash top ```
What to look for:
- High `%CPU` processes (possible infinite loops, heavy traffic, misbehaving jobs)
- Low “free” memory is not always bad (Linux uses cache), but swap usage and constant swapping is a red flag.
- Load average (high load can indicate CPU pressure or blocked I/O)
- Use `top` to note the process name (e.g., `php-fpm`, `mysqld`, `java`)
- Then check service logs:
---
Disk usage and capacity: `df` (avoid “disk full” outages)
Disk-full conditions are common causes of outages (databases fail, logs can’t write, services crash).
Check filesystem capacity:
```bash df -h ```
- `Use%` near 100% means you’re in danger.
- Pay attention to `/`, `/var`, and any mounted volumes used for databases or uploads.
---
Downloading and testing connectivity: `curl` and `wget`
You’ll often need to test HTTP endpoints, fetch files, or validate that a service is reachable.
`curl` basics (API and HTTP troubleshooting)
Fetch a page:
```bash curl https://example.com ```
Show response headers (very useful):
```bash curl -I https://example.com ```
Test a local service endpoint:
```bash curl -I http://127.0.0.1:8080 ```
Practical example: verify a reverse proxy is serving correctly:
```bash curl -I https://yourdomain.com ```
Look for:
- `200 OK` (success)
- `301/302` (redirects)
- `403` (permissions/auth)
- `404` (wrong path)
- `502/504` (upstream/app issues)
`wget` basics (downloading files)
Download a file:
```bash wget https://example.com/file.tar.gz ```
Download to a specific filename:
```bash wget -O app.tar.gz https://example.com/releases/latest.tar.gz ```
`wget` is often used in provisioning scripts because it’s straightforward for file retrieval.
---
Basic troubleshooting workflow (repeatable and safe)
When something breaks, avoid random changes. Use a consistent checklist:
1) Confirm what’s failing and where
- Is it a website? An API? SSH? A background job?
- Can you reproduce it locally (from the server) with `curl`?
```bash curl -I http://127.0.0.1 curl -I https://yourdomain.com ```
If local works but external fails, suspect firewall, DNS, TLS, or proxy configuration.
2) Check the service state
Use `systemctl`:```bash systemctl status nginx systemctl status mysql systemctl status ssh ```
If it’s inactive/failed, don’t guess—go to logs.
3) Read logs (most problems announce themselves)
Use `journalctl`:```bash journalctl -u nginx --since "1 hour ago" journalctl -u mysql --since "1 hour ago" ```
Search within logs quickly with `grep`:
```bash journalctl -u nginx --since "1 hour ago" | grep -i "error" ```
4) Check resource pressure (CPU/RAM/disk)
- CPU/memory/processes:
- Disk capacity:
If disk is full, services may fail to start or write logs. If CPU is maxed, requests may time out.
5) Validate permissions when files won’t load
If a web server can’t read files or scripts won’t run, inspect permissions and adjust carefully with `chmod`.Example: make a deploy script executable:
```bash chmod +x /usr/local/bin/deploy.sh ```
---
Practical scenarios you’ll encounter
Scenario A: “The website is down (502 Bad Gateway)”
1. Test locally: ```bash curl -I http://127.0.0.1 ``` 2. Check reverse proxy (e.g., nginx): ```bash systemctl status nginx journalctl -u nginx --since "30 min ago" ``` 3. Check app service (e.g., php-fpm): ```bash systemctl status php8.2-fpm journalctl -u php8.2-fpm --since "30 min ago" ``` 4. Look for errors like “connect() failed”, “permission denied”, or upstream timeouts.Scenario B: “I changed config and now the service won’t start”
1. Check service status: ```bash systemctl status nginx ``` 2. Read logs: ```bash journalctl -u nginx --since "15 min ago" ``` 3. Use `cat`/`grep` to find the changed line: ```bash grep -R "your_setting" /etc/nginx ```Scenario C: “Server is slow”
1. Check processes: ```bash top ``` 2. Check disk space: ```bash df -h ``` 3. Correlate with logs: ```bash journalctl --since "1 hour ago" | grep -i "oom\|killed\|error" ``` (Out-of-memory kills often show up here as the kernel terminates processes.)---
Summary: your “survival” command set
- Navigate and inspect: `ls`, `cd`, `cat`
- Search text/logs: `grep`
- Fix permissions: `chmod`
- Control services: `systemctl`
- Read service logs: `journalctl`
- Monitor performance: `top`
- Check disk space: `df`
- Test HTTP and download: `curl`, `wget`