Docker daemon no longer starts after reboot. Segfault

professorfate · May 27, 2026, 5:32pm

On one of my Ubuntu 24.04 LTS machines, the Docker daemon suddenly refused starting by using systemctl right after a system reboot. I can’t bring it back to life:

mixtile@blade3n1:~$ sudo systemctl restart docker
Job for docker.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl status docker.service" and "journalctl -xeu docker.service" for details.

I can read something about a segfault:

mixtile@blade3n1:~$ systemctl status -l --no-pager docker.service
× docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: failed (Result: core-dump) since Wed 2026-05-27 19:24:49 CEST; 1min 8s ago
TriggeredBy: × docker.socket
       Docs: https://docs.docker.com
    Process: 8345 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=dumped, signal=SEGV)
   Main PID: 8345 (code=dumped, signal=SEGV)
        CPU: 3.942s

May 27 19:24:44 blade3n1 systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
May 27 19:24:49 blade3n1 systemd[1]: docker.service: Start request repeated too quickly.
May 27 19:24:49 blade3n1 systemd[1]: docker.service: Failed with result 'core-dump'.
May 27 19:24:49 blade3n1 systemd[1]: Failed to start docker.service - Docker Application Container Engine.
May 27 19:24:49 blade3n1 systemd[1]: docker.service: Consumed 3.942s CPU time.

This is what Docker left in the journal:

May 27 19:10:43 blade3n1 systemd[1]: docker.service: Scheduled restart job, restart counter is at 2.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ Automatic restarting of the unit docker.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
May 27 19:10:47 blade3n1 systemd[1]: Starting docker.service - Docker Application Container Engine...
░░ Subject: A start job for unit docker.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit docker.service has begun execution.
░░ 
░░ The job identifier is 58795.
May 27 19:10:47 blade3n1 dockerd[7521]: minpc= 0xaaaada3db9e0 min= 0xaaaada3db9e0 maxpc= 0xaaaadc3aca31 max= 0xaaaada3db9e0
May 27 19:10:47 blade3n1 dockerd[7521]: fatal error: minpc or maxpc invalid
May 27 19:10:47 blade3n1 dockerd[7521]: runtime: panic before malloc heap initialized
May 27 19:10:47 blade3n1 dockerd[7521]: runtime stack:
May 27 19:10:52 blade3n1 systemd[1]: docker.service: Main process exited, code=dumped, status=11/SEGV
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ An ExecStart= process belonging to unit docker.service has exited.
░░ 
░░ The process' exit code is 'dumped' and its exit status is 11.
May 27 19:10:52 blade3n1 systemd[1]: docker.service: Failed with result 'core-dump'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit docker.service has entered the 'failed' state with result 'core-dump'.
May 27 19:10:52 blade3n1 systemd[1]: Failed to start docker.service - Docker Application Container Engine.
░░ Subject: A start job for unit docker.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit docker.service has finished with a failure.
░░ 
░░ The job identifier is 58795 and the job result is failed.
May 27 19:10:52 blade3n1 systemd[1]: docker.service: Consumed 3.989s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit docker.service completed and consumed the indicated resources.
May 27 19:10:54 blade3n1 systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ Automatic restarting of the unit docker.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
May 27 19:10:58 blade3n1 systemd[1]: docker.service: Start request repeated too quickly.
May 27 19:10:58 blade3n1 systemd[1]: docker.service: Failed with result 'core-dump'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit docker.service has entered the 'failed' state with result 'core-dump'.
May 27 19:10:58 blade3n1 systemd[1]: Failed to start docker.service - Docker Application Container Engine.
░░ Subject: A start job for unit docker.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit docker.service has finished with a failure.
░░ 
░░ The job identifier is 59079 and the job result is failed.
May 27 19:10:58 blade3n1 systemd[1]: docker.service: Consumed 3.989s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit docker.service completed and consumed the indicated resources.

This is my system version:

Docker version 29.5.2, build 79eb04c
mixtile@blade3n1:~$ uname -a
Linux blade3n1 6.1.0-1027-rockchip #27 SMP Sun Apr 27 01:54:34 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

On my other nodes, this error does not occur, but I’ve got a slightly older version of Docker in use there: 29.4.3, build 055a478

I’ve read something about the Docker daemon crashing with a segfault, but on an age-old Raspberry Pi. So: What’s wrong here?

bluepuma77 · May 27, 2026, 7:21pm

As a first step I would recommend to upgrade to the latest version.

rimelek · May 28, 2026, 5:06pm

Have you updated something before rebooting?

The error message looks ARM-specific

fatal error: minpc or maxpc invalid

The same error was in golang

github.com/golang/go

windows/arm: fatal error: minpc or maxpc invalid

opened 08:05PM - 23 Nov 20 UTC

closed 11:30PM - 27 Nov 20 UTC

zx2c4

OS-Windows NeedsInvestigation FrozenDueToAge arch-arm

Now that we've got the windows/arm builder running, we can start looking at the …first failures. So far there are no successful tests. That could indicate an issue with the test rig, or it might indicate a latent problem with windows/arm, while it's bitrotted without a builder. Various issues seen on the farmer dashboard: ``` Building Go cmd/dist using C:\Program Files (Arm)\Go Building Go toolchain1 using C:\Program Files (Arm)\Go. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1. fatal error: minpc or maxpc invalid runtime: panic before malloc heap initialized runtime stack: fatal error: findfunc: bad findfunctab entry idx runtime: panic before malloc heap initialized panic during panic runtime stack: fatal error: findfunc: bad findfunctab entry idx runtime: panic before malloc heap initialized stack trace unavailable go tool dist: FAILED: C:\workdir\go\pkg\tool\windows_arm\go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 4 ``` ``` Building Go cmd/dist using C:\Program Files (Arm)\Go Building Go toolchain1 using C:\Program Files (Arm)\Go. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1. fatal error: minpc or maxpc invalid runtime: panic before malloc heap initialized runtime stack: fatal: morestack on g0 runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. runtime: signal received on thread not created by Go. ``` ``` Building Go cmd/dist using C:\Program Files (Arm)\Go Building Go toolchain1 using C:\Program Files (Arm)\Go. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1. fatal error: minpc or maxpc invalid runtime: panic before malloc heap initialized runtime stack: cmd/go/internal/work.init() C:/workdir/go/src/cmd/go/internal/work/security.go:198 +0x2400 fp=0x12ffc60 sp=0x12ffc4c pc=0x6f6c6c cmd/go/internal/modcmd.runVendor(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) C:/workdir/go/src/cmd/go/internal/modcmd/vendor.go:124 +0x904 fp=0x12fffe0 sp=0x12ffc60 pc=0x710e4c runtime: unexpected return pc for cmd/go/internal/clean.clean called from 0x0 stack: frame={sp:0x12fffe0, fp:0x1300198} stack=[0x12efd60,0x12ffcf8) cmd/go/internal/clean.clean(0x0) C:/workdir/go/src/cmd/go/internal/clean/clean.go:237 +0x14 fp=0x1300198 sp=0x12fffe0 pc=0x6fa12c go tool dist: FAILED: C:\workdir\go\pkg\tool\windows_arm\go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2 ``` CC @bcmills @alexbrainman @bradfitz @cagedmantis

That is a very old issue, so I doubt it is related, it can just explain why others don’t experience this. I tried it in a VM on a new MacBook, which means that was also an ARM64 Ubuntu 24.04 and Docker worked. So it is not a general arm issue either. Can you remember what changed before you rebooted?

It looks like the issue happens in the latest version while the older works.

professorfate · May 28, 2026, 5:22pm

Yes, I’ve already seen that this gremlin is related to the Go runtime, but I can’t figure out while it conquered my machine.

Yes, there has been an update of various apps. Whether the Docker CE was among them, I dunno.

rimelek · May 28, 2026, 5:38pm

Please, share the output of

docker version

That shows other important version numbers like the version of containerd or runc.

update:

You could find out by checking the apt logs

cat /var/log/apt/history.log

meyay · May 29, 2026, 5:57am

Furthermore, are you sure the installation uses a vanilla Ubuntu kernel? A customized kernel could miss required kernel modules. If Ubuntu was downloaded from Canonical’s official Ubuntu website, then it should be a vanilla kernel. If it was pre-installed or downloaded from another domain, it could be a custom kernel.

You can check if kernel modules are missing:

curl -L https://raw.githubusercontent.com/moby/moby/refs/heads/master/contrib/check-config.sh | bash

professorfate · May 29, 2026, 12:07pm

One after the other, please:

mixtile@blade3n1:~$ sudo docker version
Client: Docker Engine - Community
 Version:           29.5.2
 API version:       1.54
 Go version:        go1.26.3
 Git commit:        79eb04c
 Built:             Wed May 20 14:39:25 2026
 OS/Arch:           linux/arm64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.5.2
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.26.3
  Git commit:       568f755
  Built:            Wed May 20 14:39:25 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.4
  GitCommit:        193637f7ee8ae5f5aa5248f49e7baa3e6164966e
 runc:
  Version:          1.3.5
  GitCommit:        v1.3.5-0-g488fc13e
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Yeah, the CE has also been updated.

It’s a ready-to-flash image provided by the vendor, so yes, it could be modified. And yes, five items are in fact missing:

- Network Drivers:
  - "bridge":
    - sysctl net.ipv4.ip_forward: enabled
    - sysctl net.ipv6.conf.all.forwarding: disabled
    - sysctl net.ipv6.conf.default.forwarding: disabled
[…]
- Storage Drivers:
  […]
  - "zfs":
    - /dev/zfs: missing
    - zfs command: missing
    - zpool command: missing

Do I have to install this stuff?

rimelek · May 29, 2026, 2:55pm

I don’t think so. I have the same output for the exact same Docker CE (I got the same version numbers as you shared). ZFS is required only when you want to use the ZFS storage driver. Ipv6 is not relevant either if you don’t want to use IPv6. Even if you need that, it would not affect how the daemon starts.

Maybe you could try enabling "debug": true in /etc/docker/daemon.json and restart docker. Or if you the kernel was changed during the reboot, you could try loading the previous kernel. If that works you can try to figure out what to do with the kernel.

professorfate · May 29, 2026, 3:16pm

This file does not exist on my platform.

rimelek · May 29, 2026, 4:02pm

You can create it and add

{
  "debug": true
}

The daemon config file is not automatically created, but you can create it to override default values.

Topic		Replies	Views
Docker daemon failed to start after system reboot Docker Engine	0	11799	January 20, 2020
Failed to start the docker on the raspberry pi General	1	567	October 5, 2023
Docker stopped working after Manjaro reboot update General	0	222	July 1, 2024
Docker Daemon unable to start General docker	1	15388	September 25, 2021
Docker daemon failed to start General docker	1	4094	November 28, 2023

Docker daemon no longer starts after reboot. Segfault

Related topics