# 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 ```bash ps aux ``` Output looks like: ```plaintext 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 usage * `COMMAND` — 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. ```bash 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 ```bash 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` ```bash htop ``` `htop` is not always installed by default. Install it with: ```bash 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 ```bash df -h ``` ```plaintext 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 ` — Size of a specific directory ```bash du -sh /var/log ``` Useful for finding what's eating disk. `node_modules` and log files are common culprits. ```bash du -sh node_modules # 312M node_modules ``` ### `free -h` — RAM usage ```bash free -h ``` ```plaintext 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 ` — Send a signal to a process ```bash 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: ```bash 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 ```bash ps aux | grep node # aakib 1042 0.3 2.1 ... node server.js kill 1042 ``` Or combine both steps with `pkill`: ```bash 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: ```bash 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 ```bash 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.out` in the current directory Check the output: ```bash 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 ```bash # 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. ```bash # 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` | Filter processes by name | | `top` / `htop` | Live process monitor | | `df -h` | Disk usage | | `du -sh ` | Size of a directory | | `free -h` | RAM usage | | `kill ` | Terminate a process gracefully | | `kill -9 ` | Force kill a process | | `pkill ` | Kill all processes by name | | `nohup cmd &` | Run command that survives logout | | `tail -f ` | Follow a file's output live | | `systemctl status` | Check a service's status | | `journalctl -u -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.