Analyse de l’état interne.
Génération d’un thread dump via kill -SIGUSR1 $(pidof dockerd).
Dans les logs du journal journalctl -xe on trouve alors :
juil. 27 21:22:52 ns350873 dockerd[1763]: time="2017-07-27T21:22:52.918617952+02:00" level=info msg="goroutine stacks written to /var/run/docker/goroutine-stacks-2017-07-27T212252+0200.log"
Et dans le fichier référencé, rechercher les threads locked. Certains sont normaux (runtime.gopark, runtime.goexit - souvent présents depuis le lancement), d’autres non comme :
goroutine 15702 [syscall, 129 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._Cfunc_dm_udev_wait(0xd4d1b0a, 0x0)
github.com/docker/docker/pkg/devicemapper/_obj/_cgo_gotypes.go:418 +0x4d
github.com/docker/docker/pkg/devicemapper.dmUdevWaitFct(0xd4d1b0a, 0x138357b)
/build/docker/src/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:222 +0x2a
github.com/docker/docker/pkg/devicemapper.UdevWait(0xc423764ae0, 0x0, 0x0)
/build/docker/src/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:260 +0x39
(...)
qui dénote ici un figeage côté devicemapper.
Dans ce cas précis, le figeage se libère via dmsetup udevcomplete_all.