Every file has an owner, a group and three permission triplets for owner, group and everyone else. The kernel checks them in that order and stops at the first that applies: if you are the owner, only the owner triplet counts, even if the "others" triplet is more generous.

Read the last three lines with the diagram: /tmp ends in t (sticky: you cannot delete someone else's file even though everyone can write there), /etc/shadow is readable only by root and the shadow group, and passwd has s in the owner triplet (setuid) so an ordinary user can change their own password, which requires writing a root-owned file.

New files start from 666 and new directories from 777, and the process's umask removes bits. Umask 022 removes write for group and others, giving 644 files and 755 directories; umask 077 gives private 600 and 700. A service that writes logs or secrets should set the mode it needs explicitly rather than trust whoever started it.

Every process runs as a numeric UID and one or more GIDs; names are only a lookup in /etc/passwd and /etc/group (or LDAP and friends). UID 0 is root and bypasses permission checks. Services should never run as root: give each one a dedicated unprivileged user with no login shell, and give that user only the files it needs.

sudo runs one command as another user (root by default) after checking /etc/sudoers and the files in /etc/sudoers.d/. Always edit with visudo, which validates syntax before saving; a syntax error in sudoers can lock everyone out of root. Grant narrow rights rather than ALL:

RSS is the resident set size: RAM the process actually holds. VSZ (virtual size) is address space reserved, often several times larger for a JVM and not a useful number for "how much memory does it use".

A signal is a small notification the kernel delivers to a process. A process can catch most signals and run its own handler; two cannot be caught or ignored: SIGKILL and SIGSTOP.

Exit codes tell you how a process ended: 0 is success, 1-125 are application errors, and 128 + N means "killed by signal N". So 143 = 128 + 15 (SIGTERM) and 137 = 128 + 9 (SIGKILL). A container that "exited with 137" was killed with SIGKILL, very often by the out-of-memory killer (chapter 03) or by an orchestrator whose grace period ran out. Both codes below are real:

The script below traps TERM, does its cleanup, and exits 0. It was syntax-checked with bash -n (syntax only, no execution) and then run for real; the output is what happened here.

A Spring Boot application behaves the same way: the JVM installs a SIGTERM handler that runs shutdown hooks, and with server.shutdown=graceful Spring stops accepting new requests and lets in-flight ones finish for up to spring.lifecycle.timeout-per-shutdown-phase (30 seconds by default). A JVM that exits because of SIGTERM reports 143, which is why the systemd unit in chapter 06 declares SuccessExitStatus=143.

A zombie costs nothing but a process-table entry, and you cannot kill it (it is already dead). The fix is for the parent to call wait(), or for the parent to die so that PID 1 adopts and reaps the zombie. A pile of zombies therefore points to a buggy parent, not to the zombies. Real demonstration: a Python parent forks a child that exits at once, and the parent has not waited for it yet.

This matters in containers: if your entrypoint is a Java process that spawns helpers and never waits for them, they accumulate, because inside the container you are PID 1 and nobody adopts them. The cure is a tiny init process (docker run --init, tini) or not spawning children. The container page (page 02) returns to this.

uptime, top and /proc/loadavg show three numbers: the exponentially damped average over the last 1, 5 and 15 minutes of the number of tasks that are runnable (using or waiting for a CPU) or in uninterruptible sleep (usually waiting for disk). It is a count of demand, not a percentage.

The first three fields are the 1, 5 and 15 minute averages; 3/4562 is "tasks runnable right now / total tasks"; the last is the most recent PID. Compare the load with the number of cores: roughly 6.8 on 12 cores means about half the CPUs' worth of work was queued, healthy. On a 2-vCPU host the same 6.8 would mean three runnable tasks per CPU, and everything is slow.

top's header splits CPU time into us (user code), sy (kernel), ni (nice), id (idle), wa (waiting for I/O), hi/si (interrupts) and st (steal: time the hypervisor gave to another VM, a sign of a noisy neighbour on a cloud instance, or exhausted burst credits on a burstable AWS instance type).

Linux uses spare RAM as a page cache for file data, so "free" is normally small on a healthy, long-running machine. What matters is available: free memory plus cache that can be dropped without hurting anything.

Here only 1.0 GiB is "free", but 8.3 GiB is available, so there is no shortage. What does deserve attention on this laptop is that swap is completely used: the kernel pushed idle pages out to disk, and they will be slow the moment something touches them. Swapping is not failure by itself; sustained swap-in/out activity is. Watch it with vmstat 1 (columns si and so) rather than staring at the swap total.

• Swap is disk used as slow overflow RAM. vm.swappiness (60 on this machine) controls how eagerly the kernel swaps anonymous pages versus dropping cache. Many latency-sensitive services set it low. Kubernetes nodes have traditionally run with swap off, so check your Kubernetes version's documentation before relying on swap on a node.
• When memory cannot be freed, the kernel's OOM killer chooses a victim by oom_score (visible in /proc/PID/oom_score; it is mostly proportional to memory use) adjusted by oom_score_adj (-1000 protects a process, +1000 volunteers it). The victim gets SIGKILL, so exit code 137, and no shutdown hooks run.
• The kill is recorded in the kernel ring buffer: read it with dmesg -T (needs root on many systems, as here) or journalctl -k.

Inside a container the limit is the cgroup, not the host. A container with a 512 MiB limit and a JVM configured for a larger heap is killed at 512 MiB while the host has gigabytes free. Modern JVMs (JDK 10 onward, and 8u191) read the cgroup limit; size the heap as a percentage of it with -XX:MaxRAMPercentage (the systemd unit in chapter 06 uses 75) and leave headroom for non-heap memory.

ss (the successor of netstat) lists sockets. The options worth memorising: -t TCP, -u UDP, -l listening only, -n numeric (no DNS or service-name lookups, much faster), -p show the owning process (needs root to see other users' processes), -a all states. A temporary web server on port 18100 makes the output concrete:

Read the Local Address column: 127.0.0.1:18100 is reachable only from the same host, while 0.0.0.0:8080 (or *:8080) is reachable from outside. "It works with curl on the server but not from my laptop" is very often a service bound to loopback (server.address=127.0.0.1 in Spring) or a security group, not a code bug.

The -w timings are the quickest way to localise latency: a large dns means resolver trouble, a large connect means network or firewall, a large gap between connect and ttfb means the server is slow to answer, and a large total minus ttfb means a big or slow body. curl exit code 7 means "failed to connect" (nothing listening or refused); 28 means timeout; 6 means could not resolve host. nc -zv host port does the same connect-only check without HTTP:

Connection refused (an immediate RST) means the host is reachable but nothing listens on that port. A timeout (no answer at all) usually means a firewall or security group silently dropping packets, or a wrong route. Telling these two apart is half of network debugging.

In the second answer, 199 is the remaining TTL in seconds. Useful forms: dig +short NAME (answer only), dig @8.8.8.8 NAME (ask a specific server), dig +trace NAME (walk from the root), dig -x IP (reverse lookup), dig NAME CNAME|MX|TXT|NS. Remember that dig talks to the DNS server directly; **getent hosts follows nsswitch.conf, reads /etc/hosts first and is what applications actually do.** If dig works but the application cannot resolve, check /etc/hosts, nsswitch.conf, the search domains and the JVM's own DNS cache (the networkaddress.cache.ttl security property; check the documented defaults for your JDK version).

When the logs and the metrics disagree, the wire does not lie. tcpdump needs root. Always filter and limit (-c), because a busy interface produces thousands of lines per second.

• Flags: [S] SYN (connection attempt), [S.] SYN-ACK, [.] plain ACK, [P.] data pushed, [F.] FIN (orderly close), [R] or [R.] RST (abrupt reset).
• A SYN that repeats with no reply: dropped by a firewall. A SYN answered by R.: nothing listening. Lots of R mid-stream: a proxy or server closing idle connections.
• Do not capture traffic that contains secrets or personal data without permission, and prefer TLS-aware tools (curl -v, application logs) when the traffic is encrypted.

The unit below was written for a Spring Boot jar in /opt/orders. It was checked with systemd-analyze verify, which reported nothing for this file (the warnings in the output belonged to unrelated units already on the machine). It was not installed or started here, because that needs root.

systemd captures the service's stdout and stderr in the journal, so a Spring Boot app logging to the console needs no log file at all. Query it with journalctl; the unit name is the filter:

• On a default install the journal may be volatile (kept in memory under /run, lost at reboot) unless /var/log/journal exists or Storage=persistent is set in journald.conf. Check before you need last night's logs.
• Classic text logs still live in /var/log (syslog, auth.log, messages, nginx and others), rotated by logrotate. Use tail -F (capital F follows across rotation), less +F, and zcat or zgrep for the rotated .gz files.
• In containers and on Kubernetes the rule is the opposite: log to stdout and let the platform collect it (page 07).

The average (4.3 s) is dominated by one 30-second request. That is why dashboards show percentiles, and why you should look at the distribution before quoting a mean. Here is the same idea on the application log, extracting the took= values with grep -o:

-r prints raw strings without quotes, -s ("slurp") reads all the lines into one array so you can group_by, and -c prints compactly. Real-world uses: aws ... | jq -r '.Reservations[].Instances[].InstanceId' and kubectl get pods -o json | jq .... For files with awkward names, always pair find -print0 with xargs -0:

• Always double-quote variable expansions: "$var", "$@", "$(command)". Use single quotes when you want no expansion at all.
• Prefer [[ ... ]] over [ ... ] in bash (no word splitting inside, supports == patterns and =~ regex).
• Use $(command), never backticks; they nest and read better.
• Defaults and required values: "${PORT:-8080}" (default when unset) and "${1:?usage: script URL}" (abort with a message when missing).

wait_for_http.sh polls a health URL until it returns 200 or a timeout expires. It is the kind of step a deployment or an integration test needs after starting a service. It uses a function, a trap for cleanup, arithmetic, quoting, required and default arguments, and explicit exit codes. It was validated with bash -n and then run for real against a throw-away local server (output below the listing).

• log() writes to stderr (>&2) so that stdout stays clean for data a caller might capture.
• || true after curl stops set -e killing the script when curl exits non-zero (connection refused is exactly the case we want to retry).
• trap cleanup EXIT runs on normal exit, on exit 1, and on errors under set -e, so the temporary directory is always removed. Trap TERM and INT too if you must clean up on a kill (see sig.sh in chapter 02).
• SECONDS is a bash built-in that counts seconds since the shell started: a cheap clock for timeouts.

Two more habits: run **shellcheck** (a static analyser that spots quoting and logic bugs; not installed on this machine, so it was not run here, but it is one package install away and worth wiring into CI), and use bash -n script.sh for a syntax-only check and bash -x script.sh to trace every command as it executes.

A file descriptor (fd) is a small integer a process uses for an open file, socket, or pipe. Every client connection, every database connection, every open log file uses one. Each process has a limit, the ulimit, on how many it may hold (nofile) and on processes (nproc). Hitting it produces the infamous java.io.IOException: Too many open files or SocketException, usually under load and often only in production, where the limit is lower than on your laptop.

If the count climbs steadily and never falls, you have a leak: connections or streams that are never closed (an unclosed InputStream, an HTTP client created per request, a pool with no maximum). Raising the limit only postpones the crash; fix the leak, and set the limit high enough for legitimate peak concurrency (one fd per concurrent connection, plus files).

A namespace gives a group of processes their own private copy of one global resource. Linux has namespaces for PID (process numbering; the first process is PID 1), network (interfaces, routing table, ports), mount (the filesystem tree), UTS (hostname), IPC, user (UID mapping), plus cgroup and time. Every process is in exactly one namespace of each kind, visible as links under /proc/PID/ns; two processes share a namespace when the numbers match.

That is the whole trick: a shell that believes it is PID 1, has its own hostname and sees only its own processes. When a container runs ps, it sees a handful of processes, not the host's hundreds, for exactly this reason. Docker adds a network namespace with a virtual ethernet pair, a mount namespace whose root is the image's filesystem, and a user namespace if configured.

Control groups organise processes into a tree and enforce resource budgets and accounting per node. Modern distributions use cgroup v2 (a single hierarchy mounted at /sys/fs/cgroup, filesystem type cgroup2). Every process's group is shown in /proc/PID/cgroup; systemd puts each service in its own cgroup, which is how MemoryMax= in the unit works and how systemctl status shows per-service memory.

The single line 0::/path is the v2 format: hierarchy 0, no controller list, then the group path. For a process in a Docker container on a cgroup v2 host the path looks like 0::/system.slice/docker-<container-id>.scope seen from the host (illustrative); inside the container you usually see 0::/, because the container has its own cgroup namespace.