# Collect Docker daemon stack evidence before an unplanned restart > Docker documents a Linux SIGUSR1 stack-dump mechanism that leaves the daemon operating. Confirm the actual process and retrieve the diagnostic output separately from container logs. - Canonical URL: https://update.dsesecurity.com/updates/collect-docker-daemon-stack-evidence-before-an-unplanned-restart/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:17+00:00 - Modified: 2026-10-29T19:50:09+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Docker documents a Linux SIGUSR1 stack-dump mechanism that leaves the daemon operating. Confirm the actual process and retrieve the diagnostic output separately from container logs. ## Potentially affected Review scope: the documented native Linux Docker daemon stack-trace procedure; Windows, Docker Desktop and container application logging are excluded. ## DSE recommendation Confirm the authorized Linux daemon process, collect its documented stack evidence and retain the actual output location before choosing a separate recovery action. ## Article Bottom line: Preserve the daemon’s diagnostic state through an authorized collection step before choosing an unplanned restart. Keep the affected host, actual process and resulting evidence together so a container log is not substituted for daemon investigation. ## Source fact: documented behavior The [Read the daemon logs](https://docs.docker.com/engine/daemon/logs/) documentation is the primary reference. Docker documents sending SIGUSR1 to the Linux daemon to force a full stack trace into the diagnostic output. The guide says this stack dump does not stop the daemon; operation continues after the signal is handled. The daemon log contains either the trace or the path to its file, and the output can help identify goroutine and thread state. ## What the source does not establish This article is a diagnostic collection procedure, not a claim that the daemon is healthy or that a trace will explain every failure. It excludes Windows and Docker Desktop workflows. Keep recovery, restart approval and any application impact assessment separate from evidence collection. ## Applicability questions - Which native Linux host and daemon process are actually affected? - Who authorizes the diagnostic signal and evidence retrieval? - Which log destination or trace-file location is used on that host? - What separate observation will determine the recovery action? ## DSE recommendation: identify the process and preserve the observation DSE recommends recording the host, daemon identity, observed symptom and time before the diagnostic step. Confirm that the administrative session concerns the intended host rather than an unrelated Docker client context. Have the responsible operator identify the actual process through the approved host procedure. Use the source’s Linux stack-dump workflow only under the agreed operating authorization. Keep the documented signal distinct from a termination signal or a configuration reload. Do not improvise another signal because a familiar command did not return the expected diagnostic location. Retrieve the actual daemon log observation and any referenced trace file. Preserve timestamps, the process identity and the original diagnostic output through the restricted incident evidence process. Record a missing file or inaccessible destination as a collection failure instead of presenting unrelated application output as the requested trace. Review the evidence with the daemon owner before selecting the next intervention. Keep a restart or debug-configuration change in its own approved step, with the original collection still attributable to the pre-change state. Do not describe the absence of an obvious error in one trace as proof that the application or engine requires no further investigation. ## Verification and evidence Proposed verification, not performed: use an approved native Linux test host and harmless workload. Confirm the daemon process, perform the documented collection and record the actual log or trace-file observation. Check the agreed daemon and workload operation afterward as separate observations. Include a tabletop case for an unavailable or misidentified evidence destination so the operator can explain how the failure would remain visible. Retain the process-selection evidence, authorized invocation, timestamps, output location and actual follow-up result. Avoid deliberately making a production daemon unresponsive merely to practice collection, and do not report the proposed laboratory procedure as an incident diagnosis already completed. ## Official references - [Read the daemon logs](https://docs.docker.com/engine/daemon/logs/) — Docker Docs. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Read the daemon logs - Authority: docs.docker.com - URL: https://docs.docker.com/engine/daemon/logs/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Collect Docker daemon stack evidence before an unplanned restart,” DSE Security, https://update.dsesecurity.com/updates/collect-docker-daemon-stack-evidence-before-an-unplanned-restart/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.