🐧 Round 1: Linux Internals, Systems & Low-Level Networking

In Staff Platform Engineer and SRE interviews at top Indian tech firms (Google IDC, Uber, Razorpay, PhonePe, Atlassian, Zerodha), Round 1 is the great filter.

Junior and mid-level candidates answer with surface-level tool commands ("I run netstat", "I check top"). Staff candidates answer with kernel subsystem mechanics, memory paging structures, TCP socket state machines, and eBPF kernel hooks.

📌 Question 1: Trace the Linux Kernel Packet Ingress Flow

🎯 The Scenario & Interviewer’s Trap

“A physical server with a 10GbE NIC receives an HTTP request destined for a container running in a Kubernetes pod. Trace the packet from the physical wire all the way into the application’s user-space socket buffer. What kernel subsystems are traversed, and where can packets be silently dropped before hitting user space?”

Interviewer’s Intent: To determine if you understand the boundary between hardware interrupts, kernel SoftIRQs, the netfilter subsystem, and user-space socket buffers, or if you view networking as an opaque magic box.

💡 Staff-Level Model Answer

flowchart TD
    A["Physical Wire / Fiber"] --> B["NIC PHY & MAC Layer"]
    B --> C["NIC RX Ring Buffer (DMA Transfer)"]
    C --> D["Hard IRQ (MSI-X Interrupt to CPU)"]
    D --> E["Interrupt Handler schedules NAPI Poll (SoftIRQ NET_RX)"]
    E --> F["ksoftirqd polls NIC Ring Buffer"]
    F --> G["Allocate sk_buff (Socket Buffer)"]
    G --> H{"eBPF XDP Hook Attached?"}
    H -- "Yes: Drop or Redirect" --> H1["Early Drop / Fast Route"]
    H -- "No" --> I["Linux Network Stack: netif_receive_skb"]
    I --> J["Traffic Control (tc) Qdisc & eBPF tc-hook"]
    J --> K["Netfilter PREROUTING (conntrack & iptables/nftables)"]
    K --> L["Routing Decision (Local Process vs Forward)"]
    L --> M["Netfilter INPUT Chain"]
    M --> N["TCP Layer: tcp_v4_rcv (Sequence Check, Window Sizing)"]
    N --> O["Socket Receive Buffer (sk_rcvbuf)"]
    O --> P["epoll_wait wakes up User-Space Process (read / recvfrom)"]

Step-by-Step Kernel Execution:

1. DMA Transfer into Ring Buffer: The NIC receives electrical/optical frames. The NIC’s Direct Memory Access (DMA) engine copies packet frames directly into host RAM mapped to the NIC’s RX Ring Buffer without consuming CPU cycles.
2. Hard IRQ: When the ring buffer receives packets, the NIC fires a hardware interrupt (MSI-X) to a designated CPU core.
3. Interrupt Handler & NAPI: The CPU’s hard IRQ handler disables further NIC interrupts to avoid interrupt livelock and schedules a NAPI (New API) SoftIRQ (NET_RX_SOFTIRQ).
4. SoftIRQ & ksoftirqd: The kernel daemon ksoftirqd/<cpu> executes the driver’s NAPI poll function, draining packets from the RX ring buffer in batches (controlled by net.core.netdev_budget, default 300 packets).
5. sk_buff Allocation: The kernel allocates an sk_buff (socket buffer descriptor) for each packet.
6. XDP & Traffic Control (tc):
   • If an eBPF XDP program is loaded, it executes directly inside the driver before sk_buff allocation, enabling ultra-fast DDoS dropping or packet redirection.
   • Otherwise, the packet passes into netif_receive_skb and traverses the Traffic Control (tc) queuing discipline (qdisc).
7. Netfilter / Conntrack: The packet hits the Netfilter architecture (PREROUTING), initializing the connection tracking engine (conntrack), creating state tuple records (ORIGINAL and REPLY).
8. Routing & L4 TCP Processing: The routing subsystem checks if the destination IP is local or needs forwarding. For local pods, the packet traverses the Netfilter INPUT chain to tcp_v4_rcv().
9. Socket Receive Buffer & User Space: The kernel verifies the TCP sequence number, sends an ACK, and queues the payload into the socket’s sk_rcvbuf. An event is emitted on the socket file descriptor, waking up the application’s epoll_wait() or read() syscall.

Silent Drop Locations & CLI Diagnostic Commands:

• NIC RX Ring Buffer Overrun: Packet dropped before the OS sees it because ksoftirqd is CPU-starved.

  ethtool -S eth0 | grep -E "rx_dropped|rx_missed_errors|rx_fifo_errors"

• Netdev Backlog Queue Overflow: SoftIRQ queue (net.core.netdev_max_backlog) exhausted.

  cat /proc/net/softnet_stat
  # Column 1 = Processed packets, Column 2 = Dropped due to full backlog

• Conntrack Table Saturation: Netfilter drops new connections when the table is full.

  cat /proc/sys/net/netfilter/nf_conntrack_count
  cat /proc/sys/net/netfilter/nf_conntrack_max

• Socket Buffer Overflow: Application is too slow to read from the socket.

  netstat -s | grep -i "buffer errors"
  # Or: ss -t -i -m

🛡️ Follow-Up Gotcha & Defense

Interviewer: “If you see CPU 0 at 100% utilization while CPUs 1–15 are at 5%, and your application is experiencing packet loss, what is happening and how do you fix it?”

Staff Defense: “This is IRQ Pinning Imbalance. All NIC hardware interrupts are hitting CPU 0. I would resolve this by checking /proc/interrupts, enabling Receive Side Scaling (RSS) on the NIC with multi-queue support (ethtool -L eth0 combined 8), and configuring irqbalance or steering SoftIRQs across cores using Receive Packet Steering (RPS) via /sys/class/net/eth0/queues/rx-*/rps_cpus.”

📌 Question 2: CFS CPU Quota Throttling vs CPU Shares

🎯 The Scenario & Interviewer’s Trap

“You deploy a Go microservice in Kubernetes with resources.requests.cpu: 500m and resources.limits.cpu: 2. At peak traffic, the node CPU utilization is only 35%, and the pod’s average CPU usage is only 0.8 cores. Yet, the service’s p99 latency spikes from 15ms to 650ms. What is causing this, and how do you prove it?”

Interviewer’s Intent: To verify whether you understand the Linux Completely Fair Scheduler (CFS) bandwidth control and how multi-threaded runtimes cause micro-burst throttling within the 100ms CFS quota window.

💡 Staff-Level Model Answer

flowchart LR
    subgraph Period["100ms CFS Period (cpu.cfs_period_us)"]
        direction TB
        T1["0ms - 20ms: 8 Threads burst simultaneously"]
        T2["Consumed Quota: 8 threads × 20ms = 160ms CPU time"]
        T3["Max Allowed Quota: 2 cores × 100ms = 200ms"]
        T4["At 25ms: 200ms quota completely exhausted!"]
        T5["25ms - 100ms: ALL THREADS HARD-THROTTLED (Sleep for 75ms)"]
    end
    Period --> Result["Spike in p99 Latency (650ms) despite low average CPU!"]

The Kernel Mechanism:

• Kubernetes maps resources.limits.cpu: 2 to Linux cgroups CFS bandwidth controls:
  • cpu.cfs_period_us = 100000 (100 milliseconds).
  • cpu.cfs_quota_us = 200000 (200 milliseconds of aggregate CPU run time per 100ms period).
• When a multi-threaded application (like Go runtime with GOMAXPROCS=8 on an 8-core node, or Java JVM with thread pools) receives a burst of HTTP requests, 8 threads execute concurrently on 8 separate CPU cores.
• In just 25 milliseconds of wall-clock time, 8 threads running at 100% consume: 📐 Total CPU Time = 8 × 25ms = 200ms
• The container has completely exhausted its 200ms quota for that period. The Linux kernel deschedules all threads and places the cgroup on the throttle wait-queue for the remaining 75 milliseconds of the period.
• This cycle repeats every 100ms. Over a 1-minute Prometheus scraping interval, average CPU utilization appears low (200ms / 1000ms = 20%), but user requests spend up to 75ms waiting in the throttled state per period.

Diagnostic Verification:

# On the Kubernetes worker node (cgroups v1):
cat /sys/fs/cgroup/cpu/kubepods.slice/.../cpu.stat

# Output:
# nr_periods 12450
# nr_throttled 4320        <-- 34% of all periods throttled!
# throttled_time 285432190  <-- Nanoseconds spent throttled

In Prometheus / Grafana:

sum(rate(container_cpu_cfs_throttled_periods_total[5m])) 
/ 
sum(rate(container_cpu_cfs_periods_total[5m])) * 100

Remediation:

1. Set GOMAXPROCS explicitly: Use uber-go/automaxprocs in Go or -XX:ActiveProcessorCount in JVM to ensure the runtime does not spawn threads based on the host core count rather than container CPU limits.
2. Remove CPU Limits on Latency-Sensitive Workloads: Rely strictly on resources.requests.cpu (which configures cpu.shares, a relative priority weight that allows burst without hard throttling), while using node-level alerting and pod autoscaling (HPA) to prevent noisy neighbor starvation.

📌 Question 3: Linux Memory Management & The OOMKiller Mystery

🎯 The Scenario & Interviewer’s Trap

“A Java service running in a pod with limits.memory: 4Gi has its JVM heap configured with -Xmx2g. The application never uses more than 1.8GB of heap memory, but Kubernetes randomly terminates the pod with Exit Code 137 (OOMKilled). Why is this happening, and how does the kernel determine which process to kill?”

Interviewer’s Intent: To verify whether you know that container memory is not just heap—it includes off-heap memory, thread stacks, JVM Metaspace, and Linux kernel Page Cache / Slab allocation.

💡 Staff-Level Model Answer

flowchart TD
    subgraph TotalMem["Container cgroup Memory Limit: 4.0 GB"]
        Heap["JVM Heap (-Xmx2g): 1.8 GB"]
        OffHeap["Off-Heap & Direct Byte Buffers: 0.8 GB"]
        Metaspace["JVM Metaspace & CodeCache: 0.4 GB"]
        Stacks["Thread Stacks (500 threads × 1MB): 0.5 GB"]
        PageCache["Linux Page Cache (File I/O, Logs): 0.8 GB"]
    end
    TotalMem --> Exceed["Sum = 4.3 GB > 4.0 GB Limit"]
    Exceed --> OOM["Linux Kernel mem_cgroup_out_of_memory() Fires!"]
    OOM --> Kill["SIGKILL (137) Sent to Java Process"]

Kernel Memory Breakdown:

A container’s cgroup memory consumption (memory.usage_in_bytes) is calculated as: 📐 cgroup Memory = RSS (Resident Set Size) + Page Cache (file-backed) + Kernel Memory (Slab/Buffers)

1. JVM Non-Heap Overhead:
   • Thread Stacks: Each Java thread allocates a default 1MB native stack (-Xss1m). 500 concurrent threads consume 500MB of native RAM outside the heap.
   • Direct Byte Buffers (NIO): Netty/gRPC allocate off-heap memory directly via ByteBuffer.allocateDirect() for zero-copy I/O.
   • Metaspace & Native Libraries: Loaded classes, JIT compiler CodeCache, and glibc allocations.
2. Page Cache Dirty Pages: If the application writes heavy logs to stdout/stderr or local disk, Linux caches these writes in Page Cache. When total memory approaches the limit, the kernel invokes memory compaction and reclamation (kswapd). If the kernel cannot reclaim dirty pages fast enough to satisfy new kmalloc() allocations, it triggers mem_cgroup_out_of_memory().

The oom_score_adj Calculation:

When the cgroup memory limit is breached, the kernel calculates the oom_score for each process: 📐 oom_score = (Memory Used by Process) / (Total Available Memory) × 1000 + oom_score_adj

• In Kubernetes:
  • Guaranteed Pods: oom_score_adj = -997 (Killed last).
  • Burstable Pods: oom_score_adj = min(max(2, 1000 - (1000 × memory.requests / node.memory)), 999).
  • BestEffort Pods: oom_score_adj = 1000 (Killed first).

How to Debug:

# Check dmesg on the node:
dmesg -T | grep -i "oom-killer"

# Check container memory breakdown from cgroup:
cat /sys/fs/cgroup/memory/kubepods.slice/.../memory.stat
# Look at: rss, inactive_file, active_file, mapped_file, unevictable

📌 Question 4: TCP TIME_WAIT Accumulation & Ephemeral Port Exhaustion

🎯 The Scenario & Interviewer’s Trap

“A high-throughput API gateway running on an EC2 instance handles 15,000 outgoing HTTPS requests per second to downstream microservices. Suddenly, new outbound connections fail with Cannot assign requested address (EADDRNOTAVAIL). netstat reveals 60,000 connections in TIME_WAIT. Why does TIME_WAIT exist, why did you run out of ports, and why is tcp_tw_recycle dangerous?”

Interviewer’s Intent: To test your command of the TCP state machine, the 4-tuple connection space, socket reuse flags, and why legacy optimization hacks cause disastrous bugs in modern NAT environments.

💡 Staff-Level Model Answer

sequenceDiagram
    autonumber
    participant Client as API Gateway (Client)
    participant Server as Downstream Service
    Client->>Server: FIN (Active Close initiated by Client)
    Server-->>Client: ACK
    Server->>Client: FIN
    Client-->>Server: ACK
    Note over Client: Client enters TIME_WAIT (2 × MSL = 60s)
    Note over Client: Socket 4-tuple is locked to prevent delayed segment collision

1. Why TIME_WAIT Exists (2 × MSL):

The standard Maximum Segment Lifetime (MSL) in Linux is 30 seconds, so TIME_WAIT lasts 60 seconds (2 * MSL). It serves two crucial purposes:

1. Reliable Connection Termination: If the client’s final ACK is dropped in transit, the server re-transmits its FIN. If the client closed immediately without TIME_WAIT, it would respond with an RST, causing the server to believe an ungraceful error occurred.
2. Preventing Delayed Segment Data Corruption: Ensures old duplicate packets still floating through intermediate routers are completely discarded before a new connection with the exact same 4-tuple (SrcIP, SrcPort, DstIP, DstPort) is established.

2. The Root Cause of EADDRNOTAVAIL:

A client connecting to a specific downstream service has a fixed 3-tuple:

• Source IP = Host IP
• Destination IP = Downstream IP
• Destination Port = 443

Only the Source Port (Ephemeral Port) varies. The Linux ephemeral port range is defined in /proc/sys/net/ipv4/ip_local_port_range (typically 32768 - 60999, providing only 28,231 ports). At 15,000 connections per second without HTTP connection pooling (opening and closing a new TCP socket per request), all 28,000 ports are consumed in less than 2 seconds and locked in TIME_WAIT for 60 seconds!

3. Why tcp_tw_recycle is Dangerous and Deprecated:

• tcp_tw_recycle (removed in Linux kernel 4.12) attempted to recycle TIME_WAIT sockets rapidly by checking the TCP timestamp option (PAWS - Protect Against Wrapped Sequence numbers).
• The NAT Disaster: If multiple clients sit behind a common NAT Gateway, their outgoing packets share the same public IP but have different, desynchronized internal hardware timestamps. When Client A sends a packet with timestamp T_1, and Client B sends a packet with timestamp T_2 < T_1, the server with tcp_tw_recycle=1 drops Client B’s packet as a delayed replay, silently blackholing legitimate users!

4. The Staff-Level Solution:

# 1. Expand ephemeral port range to 64,511 ports:
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 2. Enable safe socket reuse for outbound connections:
sysctl -w net.ipv4.tcp_tw_reuse=1

# 3. Architecturally: ENFORCE HTTP Connection Pooling (Keep-Alive)
# In Go / Python / Node / Java HTTP clients:
# MaxIdleConnsPerHost = 500, IdleConnTimeout = 90s

📌 Question 5: CoreDNS UDP Conntrack Race Condition & ndots:5

🎯 The Scenario & Interviewer’s Trap

“Your Kubernetes cluster runs high-throughput microservices. Microservices randomly experience 5-second connection delays and intermittent EAI_AGAIN DNS resolution failures. When inspecting metrics, CoreDNS latency is under 2ms. What kernel race condition occurs between glibc and Linux netfilter, and how do you resolve it?”

Interviewer’s Intent: To test if you understand the classic Linux netfilter conntrack UDP race condition and how the Kubernetes default /etc/resolv.conf ndots:5 setting multiplies DNS traffic by 5x.

💡 Staff-Level Model Answer

flowchart TD
    App["Application Pod (glibc)"] -->|Simultaneous UDP Queries| Conntrack["Linux Netfilter conntrack"]
    App -->|Query 1: A Record| Conntrack
    App -->|Query 2: AAAA Record| Conntrack

    Conntrack -->|Insert Tuple 1| StateTable["State Table: src_ip, dst_ip, src_port, dst_port"]
    Conntrack -->|Insert Tuple 2: RACE!| StateTable
    
    StateTable -->|Race Condition| Drop["insert_failed: Second UDP reply silently dropped!"]
    Drop --> Timeout["Application waits for 5.0s glibc DNS timeout!"]

1. The Under-the-Hood Race Condition:

• By default, the glibc resolver sends A (IPv4) and AAAA (IPv6) DNS queries simultaneously over two separate UDP sockets using the same source port or racing for connection tracking tuples.
• In Linux netfilter (nf_conntrack), when two UDP packets with identical 5-tuples race to insert their entries into the conntrack hash table during PREROUTING, the first packet succeeds, but the second packet encounters a lock contention collision:

  # Kernel counter increments:
  net.netfilter.nf_conntrack_insert_failed

• The kernel drops the second packet. Because UDP has no built-in retransmission mechanism, the client hangs for the default glibc DNS timeout: exactly 5.0 seconds.

2. The ndots:5 Amplification Multiplier:

In Kubernetes, pods receive /etc/resolv.conf configured with:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

• If your application resolves api.stripe.com, it contains 2 dots (api . stripe . com).
• Because 2 < 5 (ndots:5), glibc assumes the domain is an internal cluster service and appends all search domains first!
• Glibc executes 5 sequential DNS lookups:
  1. api.stripe.com.default.svc.cluster.local → NXDOMAIN
  2. api.stripe.com.svc.cluster.local → NXDOMAIN
  3. api.stripe.com.cluster.local → NXDOMAIN
  4. api.stripe.com. → SUCCESS (Finally!)
• Every external API call results in 8 to 10 UDP queries (A + AAAA for each search path), maximizing conntrack churn!

3. The Enterprise Fixes:

1. Fully Qualified Domain Names (FQDN): Append a trailing dot in application code: https://api.stripe.com. (Bypasses all search domain lookups).
2. Deploy NodeLocal DNSCache: Runs a CoreDNS caching agent on every node as a DaemonSet using a link-local IP (169.254.20.10), terminating UDP queries locally and upgrading upstream cluster queries to persistent TCP connections.
3. Tune resolv.conf in Pod Spec:

   dnsConfig:
     options:
       - name: ndots
         value: "2"
       - name: single-request-reopen

   single-request-reopen directs glibc to close and reopen the socket between A and AAAA queries, completely eliminating the conntrack race.

📌 Question 6: Path MTU Discovery (PMTUD) Blackhole over IPsec / WireGuard

🎯 The Scenario & Interviewer’s Trap

“You set up a site-to-site IPsec / WireGuard tunnel between an on-premises datacenter and an AWS VPC. ping works with 0% packet loss. curl http://internal-service/health returns HTTP 200 immediately. However, when the frontend sends a large POST /upload request (10KB JSON payload), the HTTP connection freezes and eventually times out with zero bytes received. What is happening?”

Interviewer’s Intent: To test if you understand Maximum Transmission Unit (MTU), Maximum Segment Size (MSS), packet fragmentation, and why ICMP drops create silent PMTUD blackholes.

💡 Staff-Level Model Answer

flowchart TD
    Client["Client (MTU 1500)"] -->|TCP SYN: MSS 1460| Router["VPN Gateway (MTU 1420)"]
    Router -->|Tunnel Overhead: 60-80 Bytes| WireGuard["WireGuard Tunnel"]
    Client --> Small["Small GET /health: 300B"] --> WireGuard --> Passes["Passes cleanly"] --> Server["Backend Service"]
    
    Client -->|"Large POST: 1500B Packet (DF Flag Set)"| Router
    Router -->|"Cannot Fragment: DF=1"| Drop["Packet Dropped by Router!"]
    Router -.->|ICMP Type 3 Code 4: Frag Needed| Firewall{"Firewall / Security Group"}
    Firewall -- "BLOCKED! (ICMP disabled)" --> DropICMP["ICMP Dropped!"]
    DropICMP --> Blackhole["Client never receives notice: PMTUD BLACKHOLE!"]

The Architectural Root Cause:

1. Standard Ethernet frames have an MTU of 1500 bytes. The TCP Maximum Segment Size (MSS) is: 📐 MSS = MTU - IP Header (20B) - TCP Header (20B) = 1460 bytes
2. Encapsulation protocols (WireGuard, IPsec, VXLAN, GRE) add 60 to 80 bytes of encryption headers and outer IP headers. Therefore, the maximum MTU inside the VPN tunnel is reduced to 1420 or 1440 bytes.
3. All modern TCP stacks set the Don’t Fragment (DF = 1) bit in the IP header to enable Path MTU Discovery (PMTUD).
4. When a 1500-byte packet arrives at the VPN gateway, the gateway cannot fit the packet into a 1420-byte tunnel without fragmentation. Because DF=1, the gateway drops the packet.
5. The gateway generates an ICMP Type 3, Code 4 packet (Destination Unreachable, Fragmentation Needed and DF Set) back to the sender, containing the acceptable MTU (1420).
6. The Blackhole: Security engineers frequently block all ICMP traffic in firewalls or AWS Security Groups. The ICMP notification is dropped! The client never learns that 1500 bytes is too large, endlessly retransmitting the unfragmented packet until the connection times out.

The Staff-Level Fix:

• TCP MSS Clamping (Recommended): Configure the gateway router/firewall to rewrite the TCP SYN packet MSS on the fly:

  # iptables MSS clamping rule:
  iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

• Explicit MTU Tuning on WireGuard Interface:

  [Interface]
  PrivateKey = ...
  Address = 10.100.0.1/24
  MTU = 1420

• Permit ICMP Type 3 Code 4: Ensure Security Groups and perimeter firewalls permit inbound ICMP fragmentation notifications.

📌 Question 7: PID 1, Zombie Processes & Signal Forwarding in Containers

🎯 The Scenario & Interviewer’s Trap

“You deploy a Python microservice inside a Docker container where the Dockerfile specifies ENTRYPOINT ["python", "app.py"]. When Kubernetes issues a pod termination during a deployment, the pod ignores the termination signal and continues running for exactly 30 seconds until Kubernetes issues a forceful SIGKILL. In addition, inspecting ps aux inside the container reveals dozens of <defunct> zombie processes. Why is this happening, and how do you fix both issues?”

Interviewer’s Intent: To verify if you understand Linux PID Namespaces, the special behavior of PID 1 regarding signal handling, and parent process reap responsibilities.

💡 Staff-Level Model Answer

1. Why PID 1 Ignores SIGTERM:

In Linux, the process with PID 1 (traditionally systemd or init) is treated with special kernel privileges:

• For all regular processes (PID > 1), if the process does not register a custom signal handler for SIGTERM, the kernel invokes the default action: immediate termination.
• For PID 1, the kernel disables default signal handlers. If PID 1 has not explicitly registered a signal handler for SIGTERM, the kernel discards the signal entirely.
• When Kubernetes sends SIGTERM to initiate graceful shutdown, the Python runtime (running as PID 1) ignores it. Kubernetes waits for terminationGracePeriodSeconds (default 30 seconds) and then issues SIGKILL (which cannot be ignored), abruptly aborting active user transactions.

2. Why <defunct> Zombie Processes Accumulate:

• When a child process terminates, it does not immediately disappear from the kernel process table. Its status code is preserved so its parent can read it using the wait() or waitpid() syscall.
• While waiting for the parent to call wait(), the child process remains in the Zombie (Z) state.
• If the parent process dies before reaping the child, the child is orphaned and adopted by PID 1.
• A traditional init system constantly runs a loop reaping orphaned child processes. A standard application binary (Python, Node.js, Go) does not implement an orphan reaping loop. The zombie processes remain in the kernel process table indefinitely, eventually exhausting the system PID limit (/proc/sys/kernel/pid_max).

3. The Architectural Solution:

Never run raw application binaries as PID 1 in a container. Use a lightweight init supervisor like tini or dumb-init:

# Best-practice Dockerfile with tini:
FROM python:3.12-slim

# Install tini
RUN apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY app.py .

# Use tini as PID 1 entrypoint
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["python", "app.py"]

Or in Docker directly:

docker run --init my-app:latest

• tini registers proper signal handlers, forwards SIGTERM down to child process trees, and continuously executes waitpid(-1, ...) to reap zombie processes immediately.

📌 Summary: Quick-Fire Linux & Networking Drill

🧠 Complete Lesson-by-Lesson One-Line Memory Bank (Round 1 Scope)

🐧 Phase 0: The Primitives (All Lessons)

Lesson 1: Linux Primitives & systemd

Lesson 2: Networking & CIDR Math

Lesson 3: Git & GitOps Foundations

Lesson 4: Docker & Container Primitives

Lesson 5: Kernel Namespaces & cgroups

Hands-On Labs: Phase 0 Exercises

🌐 Phase 1: Enterprise Multi-Cloud Networking Lessons

Lesson 2: Transit Gateway & Egress

Lesson 4: PrivateLink, BGP & Hybrid DNS

Lesson 5: Cloud WAN, IPv6 & Network Forensics