Test your knowledge: The Nginx Debugging Toolkit

The debugging method, debug builds, /proc forensics, core dumps, and profiling.

Stuck? Each question has an optional hint.

Skip a hard question and review it before your results.

Questions and answer options can shuffle between attempts.

You can retake this quiz whenever you like.

Question 1 of 5

The debugging method's first move is always what?

Tools don't debug; method does.

Answer options A Reproduce the failure, then reduce it — a minimal reproducible case before touching any tool B Attach gdb to the master C Raise all log levels to debug D Restart with a stock config

Reproduce and reduce first: the smallest request and config that still fails tells you where to point every instrument. Skipping this step is how 50-MB debug logs of a busy site happen.

Review this lesson

Question 2 of 5

The running instance disagrees with the config file you are reading. What settles it?

-t validates; this one prints.

Answer options A nginx -t B nginx -T — dumps the fully merged, active configuration (includes expanded) to stdout C Reading the master's /proc/cmdline D nginx -V

nginx -T prints the complete effective config — every include inlined, every inherited value visible. When 'the file says X but it behaves like Y', the answer is almost always an include or a shadowing location you forgot.

Review this lesson

Question 3 of 5

`ls -l /proc/$(pgrep -f 'nginx: worker' | head -1)/fd | wc -l` is the forensics answer to what question?

The /proc tree is ground truth, not a config claim.

Answer options A How many workers exist B How many file descriptors (sockets included) that worker actually holds — evidence for worker_connections and leak hunting C The worker's CPU affinity D Its shared-memory zone sizes

Each socket and file is an fd: counting them per worker measures real load against worker_connections, and watching the count grow without bound is the smoking gun of a leak. ss/lsof alongside map fds to endpoints.

Review this lesson

Question 4 of 5

A worker segfaults nightly and the core dump is missing. The usual culprit?

Where is the worker standing when it crashes, and may it write there?

Answer options A Cores are disabled when running as non-root B No writable working_directory (workers drop root, so the default cwd rejects the dump) — plus ulimit/RLIMIT_CORE in the service unit C NGINX swallows cores by design D The kernel's core_pattern is read-only

A core lands in the process's cwd; after privilege drop that is usually not writable. Set working_directory to a dump dir and the systemd LimitCORE, and the segfault becomes a gdb backtrace instead of a mystery.

Review this lesson

Question 5 of 5

Workers peg a core but the access log looks idle. On a locked-down host with no perf access, what does the profiling lesson reach for?

Measure the function, not the directive.

Answer options A Restart with fewer workers B A sampling profiler over the busy worker — perf top / flame graphs — to see whether it is TLS, gzip, or a module loop, before changing any config C Raise worker_processes D Turn off sendfile

The rootless /proc sampler comes first on a locked-down host (Lesson 16.5: CPU%, R/S/D shape, wchan census — WHERE the time goes). With perf available, sampling the worker’s stack names the cost directly — TLS, gzip, or a module loop — and flame graphs turn the samples into a picture. Config knobs come after the receipt, never before.

Review this lesson

Test your knowledge: The Nginx Debugging Toolkit