Processes, System Monitoring & Keeping Your App Alive
Linux for Everyday Use | Part 5 of the Linux → Deploy Series
You just deployed your Next.js app on a Linux server. It's running. You type Ctrl+C to get your terminal back.
The app dies.
That's the problem this blog solves. But to get there, you need to understand how Linux thinks about running programs — what a process is, how to watch what's happening on your machine, and how to keep things alive even when you're not looking.
What Is a Process?
Every program running on your system is a process. When you run node server.js, Linux creates a process for it, assigns it a unique PID (Process ID), and tracks it.
That PID is how you talk to that process — to check it, pause it, or kill it.
Viewing Running Processes
ps aux — Snapshot of every running process
ps aux
Output looks like:
USER PID %CPU %MEM VSZ RSS COMMAND
root 1 0.0 0.1 22596 1512 /sbin/init
aakib 1042 0.3 2.1 912344 86012 node server.js
The columns that matter:
PID— the process ID%CPU— CPU usage%MEM— memory usageCOMMAND— what's actually running
Next.js use case: If you're not sure your app is running, ps aux | grep node filters the list to only show Node.js processes.
ps aux | grep node
The | (pipe) passes the output of ps aux into grep, which filters by the word "node". Pipes are one of the most powerful patterns in Linux — you'll use them constantly.
top — Live, real-time process monitor
top
This gives you a live updating dashboard of all running processes, sorted by CPU usage. Press q to quit.
top is useful for spotting a runaway process that's eating your CPU or memory.
htop — The friendlier version of top
htop
htop is not always installed by default. Install it with:
sudo apt install htop
It shows the same info as top but with color, keyboard navigation, and a much easier interface. For everyday monitoring, prefer htop.
Checking Disk and Memory
Your server has limited resources. Running out of disk space or memory will crash your app silently. Check these regularly.
df -h — Disk space usage
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 25G 8.1G 16G 34% /
-h means human-readable (shows GB/MB instead of bytes). The Use% column is what you care about. If it hits 90%+, your server is in trouble.
du -sh <path> — Size of a specific directory
du -sh /var/log
Useful for finding what's eating disk. node_modules and log files are common culprits.
du -sh node_modules
# 312M node_modules
free -h — RAM usage
free -h
total used free shared buff/cache available
Mem: 1.9G 1.1G 120M 23M 720M 680M
Swap: 1.0G 200M 800M
For a $5–$10 VPS, you typically have 1–2 GB of RAM. A Next.js app running with npm start can use 150–300 MB. Keep an eye on this — if available drops near zero, processes start getting killed by the OS.
Killing a Process
kill <PID> — Send a signal to a process
kill 1042
By default this sends SIGTERM, a polite "please shut down" signal. Most processes honor it.
If a process is frozen and won't respond:
kill -9 1042
-9 sends SIGKILL — the OS forcibly terminates it. No cleanup, no mercy. Use it as a last resort.
Finding the PID first
ps aux | grep node
# aakib 1042 0.3 2.1 ... node server.js
kill 1042
Or combine both steps with pkill:
pkill node
This kills all processes matching the name "node". Use carefully on shared servers.
Running Processes in the Background
Back to the original problem: your Next.js app dies when you close the terminal. Here's why and how to fix it.
The problem
When you run npm start, Linux ties that process to your terminal session. Close the terminal → session ends → all child processes receive SIGHUP (hangup signal) → they die.
Solution 1: & — Background a process
Append & to any command to run it in the background:
npm start &
The process keeps running even if you close the terminal... mostly. Some systems still kill it on logout. More importantly, you lose easy access to its output.
Solution 2: nohup — Immune to hangups
nohup npm start &
nohup (no hangup) tells Linux to ignore the SIGHUP signal. Combined with &, the process:
Runs in the background
Survives your logout
Writes output to
nohup.outin the current directory
Check the output:
tail -f nohup.out
tail -f follows the file live — you see new lines as they're written. Perfect for watching logs.
This works, but it's fragile. If your server reboots, your app doesn't restart automatically.
systemctl — The Proper Way to Manage Services
systemd is the init system on most modern Linux servers. It manages services — programs that should start on boot, restart on crash, and be controllable with a standard interface.
You don't need to write your own systemd unit files yet (that's covered in Blog 7). But you do need to understand how to control services you've already installed.
Common systemctl commands
# Check status of a service
sudo systemctl status nginx
# Start a service
sudo systemctl start nginx
# Stop a service
sudo systemctl stop nginx
# Restart a service (stop + start)
sudo systemctl restart nginx
# Reload config without full restart
sudo systemctl reload nginx
# Enable on boot
sudo systemctl enable nginx
# Disable on boot
sudo systemctl disable nginx
Why this matters: nginx (which you'll set up in Blog 6) is managed via systemctl. After you edit its config, sudo systemctl reload nginx applies your changes without dropping active connections.
Viewing Logs with journalctl
When a service misbehaves, its logs are in the system journal.
# Logs for a specific service
sudo journalctl -u nginx
# Follow logs live
sudo journalctl -u nginx -f
# Last 50 lines
sudo journalctl -u nginx -n 50
This is what your senior DevOps will look at first when your app goes down. Get comfortable here.
Quick Reference
| Command | What it does |
|---|---|
ps aux |
Snapshot of all processes |
| `ps aux | grep node` |
top / htop |
Live process monitor |
df -h |
Disk usage |
du -sh <path> |
Size of a directory |
free -h |
RAM usage |
kill <PID> |
Terminate a process gracefully |
kill -9 <PID> |
Force kill a process |
pkill <name> |
Kill all processes by name |
nohup cmd & |
Run command that survives logout |
tail -f <file> |
Follow a file's output live |
systemctl status |
Check a service's status |
journalctl -u <svc> -f |
Follow a service's logs |
What's Next
You can now run a process, check if it's alive, watch its resource usage, and keep it running after logout. But nohup is a hack — it won't survive a server reboot, and there's no auto-restart on crash.
In Blog 6, you'll set up SSH keys properly, understand how ports work, and configure nginx as a reverse proxy — the piece that lets the world reach your Next.js app on port 80 while your app happily runs on port 3000.
