Processes, pipes and logs for support work

A large part of support and DevOps work is answering three questions on a server: what is running, what is it doing, and what did it write to the logs. The commands below cover most of that work and most of what screenings ask.

Finding and stopping processes

ps aux lists every process with its user, process ID (PID), CPU and memory use. top shows the same information live and sorted by CPU, which is useful when a server feels slow. To stop a process, use its PID:

1. kill 4321 sends SIGTERM, asking the program to finish cleanly.
2. Wait a few seconds and check again with ps.
3. Only if it is still running, use kill -9 4321, which sends SIGKILL and cannot be ignored but gives the program no chance to save its work.

Pipes and redirection

A pipe | sends the output of one command into the next. ps aux | grep java filters the process list, and grep -i error app.log | wc -l counts error lines.

Redirection sends output to files. Every command has standard output (stream 1) and standard error (stream 2).

• > writes output to a file and replaces its contents.
• >> appends to the end of the file.
• 2>errors.txt saves only the error messages.
• > all.log 2>&1 saves output and errors together. The order matters: redirect stream 1 first, then point stream 2 at it.

Services and logs

On systemd systems, services are managed with systemctl: status, start, stop, restart and enable. Remember that start affects the current boot only, while enable controls whether the service starts at the next boot.

For logs, journalctl -u nginx shows messages from one service, and journalctl -u nginx -f follows new lines as they arrive. Many applications also write plain text files under /var/log, which you can read with tail -n 50 or follow with tail -f.

Searching

grep searches inside files, and find searches for files by name, size or age. For example, find /var/log -name "*.log" -mtime -1 lists log files changed in the last day.

Checklist for a service that is down: run systemctl status, read the last log lines with journalctl -u, check disk space with df -h, fix the cause, restart, and confirm the status again.