DevOps / Basic: shared foundations / Lesson 3

Linux, networks, and service boundaries

Trace a request through process, listener, name resolution, transport, and application behavior using scoped evidence.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Trace process, namespace, transport, and application boundaries.
Explain what each diagnostic observation proves.
Define a bounded service health contract.

A running process is only one layer

A service depends on an executable, environment, identity, working directory, files, and reachable dependencies. A process can exist while it cannot accept useful requests. Linux permissions apply to the identity actually running the service, not the administrator who inspected its files. Distinguish process lifetime from request lifetime and persistent data lifetime. Before changing anything, record the selected host or container, service instance, and observation time. Evidence from the wrong namespace or an old instance can be internally correct and still irrelevant to the failing user journey.

Follow the connection path

A client resolves a name, chooses an address, establishes transport, negotiates TLS when applicable, and sends an application request. Each stage can fail independently. Successful DNS resolution does not prove a listener exists; a TCP connection does not prove a valid HTTP response; HTTP 200 does not prove the response satisfies the business contract. The first diagnostic sequence illustrates separate Linux observations without executing them. Select the relevant destination and interface in an authorized environment, and avoid broad scans or repeated probes that become unintended load.

bash Linux read-only layer observations

getent ahosts localhost
ss -ltn
ip route show

These Linux utilities inspect name resolution, TCP listeners, and routes separately. Availability and output depend on the distribution, privileges, and network namespace; no universal output or connectivity conclusion is asserted.

Understand addresses and trust

Loopback refers to the local network context. Inside a container, localhost normally identifies that container’s network namespace rather than the host or another service. Binding to loopback differs from binding all interfaces. A listening port therefore needs both address and namespace context. TLS verifies an identity according to certificate and client policy; bypassing verification may hide the very routing error under investigation. Reverse proxies add another boundary: decide which forwarded headers are trusted, and never treat a client-supplied forwarded identity as an authorization decision.

Interpret evidence without overclaiming

The second synthetic matrix separates observations from conclusions. A listener in one namespace and a failed client in another suggests a boundary question, not an immediate firewall repair. Timeouts, refusals, and authentication failures provide different clues, but several causes can produce similar symptoms. Compare evidence close in time and correlate it with a request identifier where possible. Avoid publishing full environment dumps, packet payloads, or credential-bearing URLs. A useful diagnosis states what the observation proves, what it does not prove, and which next read-only check would distinguish the remaining hypotheses.

text Synthetic evidence matrix

observation                         established fact
name resolves to 127.0.0.1           local resolver returned loopback
listener exists in container A      A has a listening socket
client in container B is refused    B did not reach an accepting endpoint
HTTP response is 401                an HTTP peer rejected authentication

The rows are independent teaching observations. They cannot be combined into a claim that both containers share localhost or that authentication failure is a DNS failure.

Make service contracts operational

Document the intended bind address, public endpoint, dependency names, timeout policy, startup requirements, and graceful stop behavior. Readiness should mean the instance can accept new work, while liveness has a narrower restart purpose. A dependency outage should not automatically trigger restart storms across every healthy process. Include filesystem access and resource limits in the contract, because an application can fail after connecting successfully when it cannot read configuration or allocate memory. Keep diagnostic commands separate from repair commands and require evidence before widening permissions, opening ports, or disabling transport verification.

Common errors and fixes

localhost reaches the wrong component

Why it happens: The network namespace was ignored.
How to fix it: Use the documented service endpoint for that context.
Prevent it next time: Record namespace and address assumptions in deployment configuration.

A running process is called healthy

Why it happens: Process existence replaced request-level evidence.
How to fix it: Verify the intended bounded readiness contract.
Prevent it next time: Separate startup, readiness, liveness, and business checks.

TLS verification is disabled as a repair

Why it happens: Identity failure was treated as a nuisance.
How to fix it: Correct names, certificates, trust, or routing as evidence indicates.
Prevent it next time: Keep identity verification in acceptance criteria.

Check your understanding

1. DNS succeeds and the TCP connection is refused. Which layer needs investigation next?

Show worked solution

Inspect the selected address, port, listener, and namespace or an explicit rejection policy. DNS already returned an address but did not establish a service there. Do not reset credentials or disable TLS before a transport connection exists.

2. A container can reach its own localhost but not a sibling service. Explain the missing assumption.