Managing a Linux Server in Real-time

This is a worked example of looking after a Linux server when something goes wrong, and of the routine checks that stop it going wrong again. It follows one administrator through an alert on a server running AlmaLinux, Rocky Linux or Ubuntu, using current commands at each step. It applies to a server you manage yourself, such as a VPS; on shared hosting you can't run these commands or change server settings.

1. The scenario and the ground rules

Your monitoring reports that a website on your VPS is slow and sometimes times out. Before touching anything, three rules:

• Look before you change. Read-only commands first; changes only once you know the cause.
• Change one thing at a time, and note what you changed, so you can undo it.
• Keep a way back in. Don't restart SSH or change firewall rules without a second session open.

Several older tutorials use ifconfig, netstat and yum. They still exist on some systems, but ip, ss and dnf are the current tools and are what this guide uses. CentOS Linux is end of life; AlmaLinux and Rocky Linux are its drop-in replacements.

2. Log in and take a first look

ssh -i ~/.ssh/id_ed25519 [email protected]
uptime                 # load averages for 1, 5 and 15 minutes
free -h                # memory and swap in use
top                    # live view; press P for CPU order, M for memory, q to quit

Read the load average against the number of CPU cores (nproc). A load of 4 on a 4-core server is busy but coping; a load of 12 means work is queuing. If memory is nearly full and swap is growing, the server is short of RAM, which slows everything down. htop gives a friendlier view if it is installed.

3. Find what is using the resources

ps aux --sort=-%cpu | head -n 10     # top CPU users
ps aux --sort=-%mem | head -n 10     # top memory users
sudo iotop -o                        # processes doing disk I/O (install iotop first)
vmstat 2 5                           # CPU, memory, swap and I/O every 2 seconds

In our scenario, ps shows a PHP-FPM pool and a stuck backup script using most of the CPU. Before stopping anything, find out what it is: ps -fp 1234 shows its full command line, and ls -l /proc/1234/cwd (with the real process ID) shows the directory it runs from.

4. Check disk, network and logs

Disk. A full disk breaks databases, mail and logins.

df -h                                  # space per filesystem
df -i                                  # inodes; a full inode table also stops writes
sudo du -xh --max-depth=1 /var | sort -h | tail

Network.

ip -br a                               # interfaces and addresses
ss -tulpn                              # listening ports and the program behind each
ss -s                                  # connection summary; thousands of connections may mean an attack
ping -c 4 1.1.1.1 && mtr -rwc 20 example.com

Logs.

sudo journalctl -p err -b              # errors since the last boot
sudo journalctl -u nginx --since "1 hour ago"
sudo dmesg -T | grep -iE "error|oom|killed"
sudo tail -f /var/log/nginx/error.log  # use your web server's log path

An Out of memory: Killed process line in dmesg tells you the kernel ran out of RAM and killed something to survive.

5. Fix the problem safely

Stop a runaway process politely first, and forcefully only if it ignores you:

kill <PID>          # sends SIGTERM, letting it clean up
sleep 10
kill -9 <PID>       # SIGKILL, only if it is still running

If the process belongs to a service, restart the service rather than killing it:

sudo systemctl restart php8.3-fpm      # use your service name and version
sudo systemctl status php8.3-fpm

If the backup script was the cause, move it to a quiet hour and give it a lower priority with nice -n 19 ionice -c3 /path/to/backup.sh in its cron line.

6. Confirm the fix

uptime && free -h
ss -tulpn | grep -E ":80|:443"
curl -sI https://example.com | head -n 1
sudo journalctl -p err --since "10 minutes ago"

The load should fall over the next few minutes, the site should answer with a 200, and no new errors should appear. Write down what happened and what you changed.

7. Routine maintenance

Once the fire is out, make the routine automatic.

8. Hardening the server

• SSH. In /etc/ssh/sshd_config (or a file in /etc/ssh/sshd_config.d/), set PermitRootLogin no and PasswordAuthentication no once your key works, then run sudo sshd -t to test the file before sudo systemctl reload sshd. See the SSH hardening checklist.
• fail2ban. Blocks IPs that keep failing to log in. On AlmaLinux or Rocky Linux it comes from EPEL: sudo dnf install epel-release fail2ban, then sudo systemctl enable --now fail2ban. On Ubuntu: sudo apt install fail2ban.
• Database. For MariaDB, run sudo mariadb-secure-installation on a new server, and keep the database listening on 127.0.0.1 unless another server really needs it.
• Regular audits. Lynis reviews your configuration and suggests fixes: sudo lynis audit system. Schedule it weekly and read the report.
• Kernel tuning. Change sysctl values only to solve a measured problem. Settings copied from old guides, such as tcp_window_scaling, are already on by default in current kernels.

For firewalls, current guidance favours firewalld, ufw or nftables. The CSF firewall is no longer developed by its original author, so don't choose it for a new server. See modern firewall management with nftables.

9. Running this on a Domain India VPS

Everything above applies to a server you control. A Domain India VPS is self-managed: you get root access and look after the software, updates and security yourself.

• Rebooting. Reboot from inside the server with sudo reboot. Don't use poweroff or shutdown -h: a VPS you switch off from inside stays off until support starts it again.
• When the VPS stops responding, or you need it started, force-restarted, reinstalled or resized, open a ticket with the VPS's IP address and support will do it. See managing your VPS.
• On shared hosting (cPanel, DirectAdmin or Webuzo) you can't install packages, change the firewall or restart services. Use your control panel's tools, and ask support for anything at server level.

Prices on the cards are live Domain India list prices and exclude 18% GST.

Frequently asked questions

Ready to run your own server? Compare VPS plans, read the essential Linux commands guide, or open a support ticket if your VPS needs a restart from our side.