Process Management in Linux: ps, kill, systemd, and journalctl

Introduction / Why This Matters

Process management is one of the key tasks for a system administrator and developer in Linux. Understanding how to find, analyze, terminate, and control services allows you to quickly diagnose performance issues, free up resources, and ensure stable system operation. This guide covers both basic commands (ps, kill) and the modern approach via systemd and journalctl log analysis.

Requirements / Preparation

1. Terminal access with standard user privileges. To terminate other users' processes and manage services (systemctl, kill on foreign PIDs), sudo rights will be required.
2. Installed basic utilities: procps (contains ps, top), sysstat (contains pidstat), htop (optional, more convenient alternative to top), systemd (standard for most modern distributions).
3. Knowledge of PID (Process ID) — a unique process identifier. It can be obtained via ps or top.

Step 1: Finding and Monitoring Active Processes

Static View: ps aux

The ps aux command outputs a full list of all processes run by all users.

ps aux

Key columns:

• USER — process owner.
• PID — process identifier (most important for management).
• %CPU, %MEM — resource usage.
• COMMAND — the command that launched the process.

Filtering: Use grep to search by name.

ps aux | grep nginx

Interactive Monitoring: top and htop

• top — standard utility. Press q to exit, k to terminate a process (will prompt for PID).
• htop — improved version with colors, a convenient interface, and the ability to terminate a process via F9. Installation: sudo apt install htop (Debian/Ubuntu) or sudo yum install htop (RHEL/CentOS).

htop

Search by PID or Name: pgrep and pidof

• pgrep <process_name> — will return the PID of all processes whose name matches.
• pidof <process_name> — similar, but less flexible.

pgrep -l nginx  # Will show PID and name

Step 2: Terminating Processes (Signals)

Processes are terminated by sending signals. The main ones:

• SIGTERM (15) — a polite request to exit. The process can handle the signal, finish operations, and exit. Recommended first option.
• SIGKILL (9) — forceful termination. The kernel immediately kills the process. Cannot be ignored or handled. Use if SIGTERM didn't work.
• SIGHUP (1) — reload. Often used for services to reread the configuration without a full stop.

Commands for Sending Signals

1. kill <PID> — sends SIGTERM (15) by default.

   kill 1234
   

2. kill -s SIGKILL <PID> or kill -9 <PID> — sends SIGKILL.

   kill -9 1234
   

3. pkill <process_name> — terminates all processes by name (sends SIGTERM).

   pkill nginx
   

4. killall <process_name> — similar to pkill, but matches the command name more precisely.

   killall -9 nginx  # Forcefully terminate all nginx
   

Step 3: Managing systemd Services

In modern Linux (Ubuntu 16.04+, CentOS 7+, Fedora), working with long-running processes (daemons) is primarily done through systemd.

Basic systemctl Commands

• systemctl status <service> — detailed status, recent logs.

  systemctl status nginx
  

• sudo systemctl start/stop/restart <service> — state management.

  sudo systemctl restart nginx
  

• sudo systemctl enable/disable <service> — enable/disable autostart on boot.

  sudo systemctl enable nginx
  

• systemctl list-units --type=service --state=running — list all running services.

Management via service (legacy, but compatible)

On some older systems (or for compatibility), you can use:

sudo service nginx restart

But systemctl is the preferred and more powerful tool.

Step 4: Viewing Service Logs with journalctl

systemd logs are collected in the journal. The journalctl utility is the primary tool for reading them.

Common Scenarios

• Logs for a specific service:

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

• Real-time tracking (like tail -f):

  journalctl -u nginx.service -f
  

• Logs since the last boot:

  journalctl -b -u nginx.service
  

• Filter by priority (e.g., errors only):

  journalctl -u nginx.service -p err
  

• Show logs for a specific PID:

  journalctl _PID=1234
  

Step 5: Finding Processes by Ports and Files

Sometimes you need to find which process is using a specific network port or file.

By Port: ss (recommended) or netstat

sudo ss -tulpn | grep :80
# -t: TCP, -u: UDP, -l: listening, -p: show process, -n: numeric

The output will show pid and process name.

By File: lsof (List Open Files)

sudo lsof /var/log/nginx/access.log

Will show all processes that have the specified file open (read/write).

Verification

1. After terminating a process: Ensure the PID no longer appears in ps aux or top.

   ps aux | grep <process_name>
   

2. After managing a systemd service: Check the status.

   systemctl is-active <service>  # Should return 'active'
   systemctl is-enabled <service> # Should return 'enabled' (if you enabled it)
   

3. After changing configuration: Restart the service and check logs for errors.

   sudo systemctl restart <service>
   journalctl -u <service>.service -n 50 --no-pager
   

Potential Issues

1. "Operation not permitted" with kill or systemctl

• Cause: You are trying to terminate a process owned by another user (usually root) without sudo privileges.
• Solution: Use sudo kill <PID> or sudo systemctl ....

2. Process doesn't terminate even after kill -9

• Cause: The process might be in state Z (zombie) or D (uninterruptible sleep, usually waiting for I/O).
• Solution:
  • Zombie: This is already a terminated process waiting for its parent to read its status. It cannot be killed; you need to restart the parent process.
  • State D: Often caused by NFS issues or a "stuck" hardware driver. The only solution is a system reboot or fixing the I/O hang.

3. systemd service fails to start after start

• Cause: Error in the service's .service configuration file or in the application itself.
• Solution: Check the logs immediately after the start attempt.

  sudo systemctl start <service>
  journalctl -u <service>.service -n 50 --no-pager  # Will show last 50 lines
  

  Look for lines with Failed or Error.

4. journalctl shows "No journal files were found"

• Cause: Journaling is disabled or logs have been cleared. This sometimes happens in minimalist containers (Docker) or if /etc/systemd/journald.conf has Storage=none.
• Solution: Check the config sudo cat /etc/systemd/journald.conf. To enable persistent storage, uncomment Storage=auto (or persistent) and restart sudo systemctl restart systemd-journald. If you need to save logs, configure rotation.