How to fix Error response from daemon: error while creating syslog logger: dial unix: connection refused in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 204 views

This error occurs when Docker cannot connect to the syslog service via a Unix socket. The syslog daemon is either not running, the socket path is incorrect, or the wrong socket protocol is being used. The fix typically involves starting syslog, using the correct socket address format, or switching to a network-based syslog target.

Quick fix

Fixes Error response from daemon: error while creating syslog logger: dial unix: connection refused

sudo systemctl status rsyslog
  1. Check if syslog service is running
  2. Verify the syslog socket exists
  3. Use the correct socket protocol (unixgram)
  4. Use network-based syslog instead of Unix socket
docker — error
sudo systemctl status rsyslog
Error response from daemon: error while creating syslog logger: dial unix: connection refused

What this error means

When you configure Docker to use the syslog logging driver, Docker attempts to connect to a syslog service to send container logs. By default, Docker tries to connect to the local syslog daemon via a Unix socket (typically `/dev/log`). The "error while creating syslog logger: dial unix: connection refused" error indicates that Docker attempted to establish a connection to the syslog Unix socket but failed. This can happen for several reasons: - **Syslog service not running**: The rsyslog, syslog-ng, or similar service is not started on the host - **Socket doesn't exist**: The Unix socket file (usually `/dev/log`) doesn't exist because no syslog daemon has created it - **Wrong socket protocol**: Docker is using `unix://` when it should use `unixgram://` (syslog uses datagram sockets, not stream sockets) - **Wrong socket path**: The configured socket path doesn't match where the syslog service created its socket - **Container isolation**: If running syslog inside a container, the socket may not be accessible from outside This error prevents the container from starting because Docker cannot initialize the logging driver, which is required before the container can run.

Typical symptoms

  • Container fails to start with 'error while creating syslog logger: dial unix: connection refused'
  • Docker run command with --log-driver=syslog fails immediately
  • Docker Compose services with syslog logging driver won't start
  • Error appears in docker daemon logs or container start output
  • Container starts successfully when syslog logging driver is removed
  • Other containers using json-file or journald logging drivers work fine
  • Error mentions 'failed to initialize logging driver: dial unix'

Common causes

  1. Syslog service (rsyslog, syslog-ng) is not running on the host
  2. Using unix:// instead of unixgram:// for the syslog-address option
  3. The /dev/log socket file does not exist
  4. Remote syslog server is down or unreachable when using TCP/UDP
  5. Incorrect socket path specified in syslog-address option
  6. SELinux or AppArmor blocking access to the syslog socket
  7. Docker daemon started before syslog service created its socket
  8. Container environment doesn't have /dev/log mounted

How to fix "Error response from daemon: error while creating syslog logger: dial unix: connection refused"

1Check if syslog service is running

First, verify that a syslog daemon is running on your host system:

Check rsyslog (most common on Debian/Ubuntu):

bash
sudo systemctl status rsyslog

Check syslog-ng (alternative daemon):

bash
sudo systemctl status syslog-ng

If the service is not running, start it:

bash
# For rsyslog
sudo systemctl start rsyslog
sudo systemctl enable rsyslog

# For syslog-ng
sudo systemctl start syslog-ng
sudo systemctl enable syslog-ng

Install rsyslog if not present:

bash
# Debian/Ubuntu
sudo apt-get install rsyslog

# RHEL/CentOS/Fedora
sudo dnf install rsyslog
2Verify the syslog socket exists

Check if the Unix socket file exists at the expected location:

bash
ls -la /dev/log

You should see output like:

bash
srw-rw-rw- 1 root root 0 Jan 1 12:00 /dev/log

The s at the beginning indicates it's a socket file.

If /dev/log doesn't exist:

1. The syslog service may not be running
2. The socket might be at a different location (check /var/run/syslog or /run/systemd/journal/syslog)
3. On some systems, journald provides the socket

Find where syslog is listening:

bash
# Check rsyslog configuration
grep -r "imuxsock" /etc/rsyslog.conf /etc/rsyslog.d/

# Check what's listening on syslog sockets
sudo ss -xl | grep -E "(syslog|log)"
3Use the correct socket protocol (unixgram)

A common mistake is using unix:// instead of unixgram://. Syslog over Unix sockets uses datagram (UDP-like) protocol, not stream (TCP-like) protocol.

WRONG - stream socket:

bash
docker run --log-driver=syslog \
  --log-opt syslog-address=unix:///dev/log \
  my-container

CORRECT - datagram socket:

bash
docker run --log-driver=syslog \
  --log-opt syslog-address=unixgram:///dev/log \
  my-container

In docker-compose.yml:

yaml
services:
  my-service:
    image: my-image
    logging:
      driver: "syslog"
      options:
        syslog-address: "unixgram:///dev/log"
        tag: "{{.Name}}"

In daemon.json (for all containers):

json
{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "unixgram:///dev/log"
  }
}
4Use network-based syslog instead of Unix socket

If the Unix socket approach continues to cause issues, consider using UDP or TCP to send logs to a syslog server:

UDP syslog (recommended for reliability):

bash
docker run --log-driver=syslog \
  --log-opt syslog-address=udp://127.0.0.1:514 \
  my-container

TCP syslog:

bash
docker run --log-driver=syslog \
  --log-opt syslog-address=tcp://127.0.0.1:514 \
  my-container

Configure rsyslog to listen on UDP/TCP:

Edit /etc/rsyslog.conf and uncomment these lines:

bash
# For UDP
module(load="imudp")
input(type="imudp" port="514")

# For TCP
module(load="imtcp")
input(type="imtcp" port="514")

Then restart rsyslog:

bash
sudo systemctl restart rsyslog

Note: UDP is generally preferred because if the syslog server is temporarily unavailable, the container can still start (logs are simply dropped). With TCP, Docker may block waiting for the connection.

5Mount /dev/log into the container (for container-based syslog)

If you're running your application in a container and want it to log to the host's syslog, you need to mount the socket:

bash
docker run -v /dev/log:/dev/log my-container

In docker-compose.yml:

yaml
services:
  my-service:
    image: my-image
    volumes:
      - /dev/log:/dev/log

Important considerations:

- This mounts the host's syslog socket into the container
- The container's application can then use standard syslog calls
- This is different from using Docker's syslog logging driver
- Works well when your application uses syslog internally

For Docker's logging driver (not application syslog):

The logging driver connects from the Docker daemon (on the host), not from inside the container. So mounting /dev/log is only needed if your application uses syslog directly.

6Check for SELinux or AppArmor restrictions

Security modules might prevent Docker from accessing the syslog socket:

Check SELinux status (RHEL/CentOS/Fedora):

bash
getenforce

Temporarily disable SELinux to test:

bash
sudo setenforce 0

If that fixes the issue, you can create a proper SELinux policy:

bash
sudo ausearch -m avc -ts recent | audit2allow -M docker-syslog
sudo semodule -i docker-syslog.pp
sudo setenforce 1

Check AppArmor status (Ubuntu):

bash
sudo aa-status

Check for AppArmor denials:

bash
sudo dmesg | grep -i apparmor | grep -i denied

Temporarily disable Docker's AppArmor profile:

bash
docker run --security-opt apparmor=unconfined --log-driver=syslog ...
7Ensure proper service startup order

Docker might start before the syslog service creates its socket. Ensure proper startup order:

Check systemd dependencies:

bash
sudo systemctl show docker.service | grep -i after

Add dependency on syslog:

Create a systemd override file:

bash
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo cat << 'EOF' > /etc/systemd/system/docker.service.d/syslog.conf
[Unit]
After=rsyslog.service
Wants=rsyslog.service
EOF

Reload and restart:

bash
sudo systemctl daemon-reload
sudo systemctl restart docker

This ensures Docker waits for rsyslog to start before attempting to initialize.

8Use non-blocking mode to prevent container startup failures

Docker supports non-blocking log delivery, which prevents containers from failing to start when the logging backend is unavailable:

bash
docker run --log-driver=syslog \
  --log-opt mode=non-blocking \
  --log-opt max-buffer-size=4m \
  --log-opt syslog-address=unixgram:///dev/log \
  my-container

In daemon.json:

json
{
  "log-driver": "syslog",
  "log-opts": {
    "mode": "non-blocking",
    "max-buffer-size": "4m",
    "syslog-address": "unixgram:///dev/log"
  }
}

How it works:

- Log messages are stored in an intermediate buffer
- If the syslog backend is down, messages queue up (up to max-buffer-size)
- When the buffer fills, oldest messages are dropped
- The container continues running regardless of syslog availability

Note: This won't fix the initial connection error - Docker still needs to connect at startup. But it helps with temporary syslog outages.

9Verify the fix

After making changes, test that the syslog logging driver works:

Test with a simple container:

bash
docker run --rm --log-driver=syslog \
  --log-opt syslog-address=unixgram:///dev/log \
  --log-opt tag="docker-test" \
  alpine echo "Syslog test message"

Check that the message arrived in syslog:

bash
sudo grep "docker-test" /var/log/syslog
# or
sudo journalctl -t docker-test

Test your actual container:

bash
docker run --log-driver=syslog \
  --log-opt syslog-address=unixgram:///dev/log \
  your-image

If using daemon.json, restart Docker first:

bash
sudo systemctl restart docker
docker info | grep "Logging Driver"

The output should show syslog as the logging driver.

Advanced notes

### Understanding Docker Syslog Logging Driver

Docker's syslog logging driver sends container logs to a syslog server. It supports multiple transport protocols:

| Protocol | Format | Use Case |
|----------|--------|----------|
| unixgram:// | Unix datagram socket | Local syslog (default path: /dev/log) |
| unix:// | Unix stream socket | Rarely used for syslog |
| udp:// | UDP network | Remote syslog, tolerates downtime |
| tcp:// | TCP network | Reliable remote syslog |
| tcp+tls:// | TLS-encrypted TCP | Secure remote syslog |

### Syslog Message Format Options

Docker supports multiple syslog message formats:

bash
docker run --log-driver=syslog \
  --log-opt syslog-format=rfc5424 \
  my-container

Available formats:
- rfc5424 - Modern syslog format with structured data
- rfc5424micro - RFC 5424 with microsecond timestamps
- rfc3164 - Traditional BSD syslog format (default)

### Configuring Syslog Facility and Tag

bash
docker run --log-driver=syslog \
  --log-opt syslog-facility=local0 \
  --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" \
  my-container

Facilities: kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0-local7

### Remote Syslog Server Configuration

For centralized logging to a remote syslog server (like Graylog, Loggly, or Papertrail):

json
{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "tcp+tls://logs.example.com:6514",
    "syslog-tls-ca-cert": "/etc/docker/ca.pem",
    "syslog-tls-cert": "/etc/docker/client-cert.pem",
    "syslog-tls-key": "/etc/docker/client-key.pem",
    "syslog-tls-skip-verify": "false",
    "tag": "{{.ImageName}}/{{.Name}}"
  }
}

### Handling Remote Server Downtime

When using TCP for remote syslog, Docker will fail to start containers if the server is unavailable. This is a known issue (GitHub #21966).

Workarounds:

1. Use UDP instead of TCP - Logs may be lost but containers start
2. Use non-blocking mode - Buffers logs during outages
3. Use a local syslog relay - Run rsyslog locally that forwards to remote
4. Use journald driver - Then configure journald to forward to syslog

### Running Syslog Inside Containers

If you need syslog inside a container (for applications that require it):

dockerfile
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y rsyslog
# Disable kernel log reading (not available in containers)
RUN sed -i 's/module(load="imklog")/#module(load="imklog")/g' /etc/rsyslog.conf
CMD ["rsyslogd", "-n"]

Or use a sidecar pattern with a logging container.

### Alternative: Use journald Driver

On systemd-based systems, the journald driver is often more reliable:

bash
docker run --log-driver=journald my-container

Then configure journald to forward to syslog in /etc/systemd/journald.conf:

ini
[Journal]
ForwardToSyslog=yes

This provides the reliability of journald with syslog integration.

Frequently asked questions

What does "Error response from daemon: error while creating syslog logger: dial u" mean?
When you configure Docker to use the syslog logging driver, Docker attempts to connect to a syslog service to send container logs. By default, Docker tries to connect to the local syslog daemon via a Unix socket (typically /dev/log). The "error while creating syslog logger: dial unix: connection refused" error indicates that Docker attempted to establish a connection to the syslog Unix socket but failed.
How do I fix "Error response from daemon: error while creating syslog logger: dial u"?
This error occurs when Docker cannot connect to the syslog service via a Unix socket. The syslog daemon is either not running, the socket path is incorrect, or the wrong socket protocol is being used. The fix typically involves starting syslog, using the correct socket address format, or switching to a network-based syslog target.
What causes "Error response from daemon: error while creating syslog logger: dial u"?
Syslog service (rsyslog, syslog-ng) is not running on the host Using unix:// instead of unixgram:// for the syslog-address option The /dev/log socket file does not exist
Is the "Error response from daemon: error while creating syslog logger: dial u" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading