Zablokowany system plików po restarcie usługi docker

W trakcie aktualizacji systemu (apt-get upgrade) uwzględniającej pakiet docker-engine, restartowana jest usługa docker, co wiąże się z zatrzymaniem wszystkich kontenerów.

Teoretycznie, kontenery stworzone z restart policy ustawionym na „always” powinny się same uruchomić, nam jednak ostatnio pojawił się nam problem z podniesieniem jednego z kontenerów będącego częścią multi-kontenerowej aplikacji:

~:# docker-compose up -d
...
ERROR: for app oci runtime error: container with id exists: b10b023395
...

Ręczne interwencje jak i próby usunięcia kontenera nic nie dawały:

~:# docker-compose restart app
Restarting app ... error
ERROR: for app Cannot restart container b10b023395: oci runtime error: container with id exists: b10b023395

~:# docker rm app
Error response from daemon: Driver btrfs failed to remove root filesystem b10b023395: Failed to destroy btrfs snapshot /var/lib/docker/btrfs/subvolumes for 94f08a2322: device or resource busy

Również próby bezpośredniego usunięcia wskazywanego snapshotu przy użyciu btrfs subvolume delete kończyły się niepowodzeniem z komunikatem „device or resource busy”. Szybkie wyszukiwanie rozwiązania problemu w internecie prowadziło tylko do dość starych błędów w samym dockerze, które nie były związane z naszym przypadkiem.

Dopiero użycie komendy lsof na ścieżce problematycznego snapshotu ujawniło, że procesy naszego kontenera, które teoretycznie powinny zostać zamknięte w czasie jego zatrzymania, nadal pracowały (!!!) blokując system plików. Ostatecznie problem został rozwiązany po zabiciu tych procesów:

~:# lsof -Fp /var/lib/docker/btrfs/subvolumes/94f08a2322 | tr -d 'p' | xargs kill -TERM