Home Explore Blog CI



docker

3rd chunk of `content/manuals/engine/daemon/logs.md`
b3c48dedf04c0358e8eb7f0e9dc5726a814144a252e912600000000100000bfc
1.  Edit the `daemon.json` file, which is usually located in `/etc/docker/`. You
    may need to create this file, if it doesn't yet exist. On macOS or Windows,
    don't edit the file directly. Instead, edit the file through the Docker Desktop settings.

2.  If the file is empty, add the following:

    ```json
    {
      "debug": true
    }
    ```

    If the file already contains JSON, just add the key `"debug": true`, being
    careful to add a comma to the end of the line if it's not the last line
    before the closing bracket. Also verify that if the `log-level` key is set,
    it's set to either `info` or `debug`. `info` is the default, and possible
    values are `debug`, `info`, `warn`, `error`, `fatal`.

3.  Send a `HUP` signal to the daemon to cause it to reload its configuration.
    On Linux hosts, use the following command.

    ```console
    $ sudo kill -SIGHUP $(pidof dockerd)
    ```

    On Windows hosts, restart Docker.

Instead of following this procedure, you can also stop the Docker daemon and
restart it manually with the debug flag `-D`. However, this may result in Docker
restarting with a different environment than the one the hosts' startup scripts
create, and this may make debugging more difficult.

## Force a stack trace to be logged

If the daemon is unresponsive, you can force a full stack trace to be logged by
sending a `SIGUSR1` signal to the daemon.

- **Linux**:

  ```console
  $ sudo kill -SIGUSR1 $(pidof dockerd)
  ```

- **Windows Server**:

  Download [docker-signal](https://github.com/moby/docker-signal).

  Get the process ID of dockerd `Get-Process dockerd`.

  Run the executable with the flag `--pid=<PID of daemon>`.

This forces a stack trace to be logged but doesn't stop the daemon. Daemon logs
show the stack trace or the path to a file containing the stack trace if it was
logged to a file.

The daemon continues operating after handling the `SIGUSR1` signal and dumping
the stack traces to the log. The stack traces can be used to determine the state
of all goroutines and threads within the daemon.

## View stack traces

The Docker daemon log can be viewed by using one of the following methods:

- By running `journalctl -u docker.service` on Linux systems using `systemctl`
- `/var/log/messages`, `/var/log/daemon.log`, or `/var/log/docker.log` on older
  Linux systems

> [!NOTE]
>
> It isn't possible to manually generate a stack trace on Docker Desktop for
> Mac or Docker Desktop for Windows. However, you can click the Docker taskbar
> icon and choose **Troubleshoot** to send information to Docker if you run into
> issues.

Look in the Docker logs for a message like the following:

```none
...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log
```

The locations where Docker saves these stack traces and dumps depends on your
operating system and configuration. You can sometimes get useful diagnostic
information straight from the stack traces and dumps. Otherwise, you can provide
this information to Docker for help diagnosing the problem.

Title: Debugging Docker Daemon: Forcing Stack Traces and Viewing Logs
Summary
This section explains how to force a stack trace to be logged when the Docker daemon is unresponsive by sending a `SIGUSR1` signal on Linux or using `docker-signal` on Windows Server. It also details how to view the Docker daemon logs using `journalctl` or log files on Linux and mentions the Docker Desktop troubleshooting options for Mac and Windows. The logs may contain stack traces that can be used for diagnostics or shared with Docker support.