Linux / Networks / Reliability

Understand the system.
Then change it.

Field notes on the layers between a process and a packet. Practical references for understanding Linux hosts, tracing network behavior, and making operations more predictable.

Explore the notebook →Plain text thinking. Observable results.

terminal — start with observation

# Inspect interfaces, routes, and listening sockets
$ ip -br address
$ ip route
$ ss -lnt
# Compare what is configured with what is running.

The notebook

Three starting points

Linux internals

Processes, resource limits, and the evidence behind a performance hypothesis.

Network paths

Separate name resolution, routing, transport, and application behavior.

Reliable operations

Small changes, clear checkpoints, and service state you can explain.

Working notes

A practical reference

KERNELObservation before tuning

Build a baseline before changing a limit

Start with the workload and the symptom. CPU utilization, memory pressure, open files, and socket state describe different constraints. Keep the measurement window and the running configuration alongside each observation.

uptime
free -h
vmstat 1 5
cat /proc/sys/fs/file-max

A configured limit is a ceiling, not a measurement of current demand. Record one baseline, change one variable, and repeat the same observation before drawing a conclusion.

NETWORKTrace the layers

A reachable port is only one piece of the path

Check the resolved address, the selected route, the listening process, and the application response separately. A local socket and a remote handshake answer different questions. Read both sides when the evidence disagrees.

getent ahostsv4 example.com
ip route get 1.1.1.1
ss -lntp
curl --head --max-time 10 https://example.com

When a connection fails, note the exact stage: resolution, connection establishment, TLS negotiation, or the application request. Keep timestamps so observations from separate hosts can be compared.

OPERATIONSMake the next step reversible

Configuration on disk is not the running service

A file can be correct while a process still uses an earlier configuration. Review the service definition, its current state, and the relevant journal entries. Validate configuration with the service's own tooling before a planned reload.

systemctl show ssh -p ActiveState -p SubState
systemctl cat ssh
journalctl -u ssh --since "30 minutes ago" --no-pager
systemctl --failed

A useful runbook explains its proof. Write down the expected result, how to observe it, and the checkpoint to return to if the change does not behave as intended.

About this notebook

Keep the context

Kernel Notes is a personal reference for Linux and network engineering. The examples favor inspection over modification and explain the reasoning that connects an observation to the next step.

How to read the command examples

Examples assume a Linux system with the named tools available. Some inspection commands require elevated privileges to show process details. Interface names, service names, and output vary between distributions. Read each command and adapt it to the host you are inspecting.

Understand the system.Then change it.