Linux processes and services
Inspect running work and its identity before interpreting it.
The idea
A process is an executing program with an identifier, user identity, resources, and relationships to other processes. Services are managed long-running functions, commonly controlled by a service manager. Useful investigative details include the executable path, command line, parent process, start time, user, and network activity. A familiar process name alone is weak evidence because names can be misleading and legitimate programs can be misused.
In practice
An analyst sees a shell launched by a service that does not normally create shells. They correlate the process tree with application logs and an approved change record.
A common misunderstanding
A process using high CPU is not automatically malicious. It may be doing legitimate expensive work or failing repeatedly.
Check your understanding
What makes a parent-child relationship useful?
Think it through: It helps explain how a process started and whether that sequence fits normal behavior.
A process name is one clue among several
A fictional analyst sees a process named updater using substantial network bandwidth. The name could describe legitimate maintenance, but it could also be misleading. Examine the executable path, parent, user identity, start time, command line, and destination context. The relationship between those facts is more informative than the name alone.
Processes are temporary observations. Identifiers can be reused after a process exits, and a process tree can change during collection. Record timing and the host context, and correlate with logs when reconstructing an earlier event. Do not assume a current process list fully explains what happened yesterday.
Service managers introduce expected launch and restart behavior. A repeatedly restarting service may create high resource use or many similar events without malicious intent. Compare the observation with configuration and change records before deciding whether the sequence is anomalous.
Explain a parent-child sequence
For a paper exercise, create a fictional web service that launches a document converter. List the expected executable, account, and arguments. Then add an unexpected shell child and identify what evidence would distinguish a legitimate maintenance action from misuse. The exercise should produce investigative questions, not an automatic verdict.
Use read-only inspection first in a training environment. Terminating an unfamiliar process can interrupt work or destroy volatile evidence, so operational response needs purpose and authority. A good incident note records what was observed, why it differs from the baseline, and what corroborates the interpretation. This approach turns process inspection into a reproducible analysis of execution and privilege rather than a search for suspicious-sounding names.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
GNU Coreutils manualLinux man-pages: Process credentials