Nie można uruchomić docker hello-world: nie znaleziono punktu montowania dla urządzeń


12

Nowy w dokerze.

Zainstalowano dokera z narzędzia do zarządzania oprogramowaniem w mint 17.

Po uruchomieniu docker run hello-worldotrzymuję:

FATA[0000] Error response from daemon: Cannot start container a6bcc1ede2c38cb6b020cf5ab35ebd51b64535af57fa44f5966c37bdf89c8781: [8] System error: mountpoint for devices not found 

Kiedy patrzę na dzienniki usług ( /var/log/upstart/docker.log), widzę:

ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH 
ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH 

: wersja dokera

Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.2.1
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.2.1
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64

: informacje o dokerze

Containers: 2
Images: 1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 5
 Dirperm1 Supported: false
Execution Driver: native-0.2
Kernel Version: 3.13.0-24-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 8
Total Memory: 15.6 GiB
Name: DWDEV-HOME-HBABAI
ID: K4GX:DTV6:547V:U3BO:YEOA:WVNU:NZEZ:L3GG:4W7U:IXNS:X3QK:5PVR
WARNING: No memory limit support
WARNING: No swap limit support

Aktualizacja:

Zainstalowano sudo apt-get install aufs-tools, uruchomiono ponownie usługę dokowania. Nie widzę już następującego błędu:

ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH 

Jednak w dziennikach widzę, że podczas uruchamiania dokera ostrzega mnie o punkcie montowania pamięci:

INFO[0000] -job init_networkdriver() = OK (0)           
/var/run/docker.sock is up
WARN[0000] mountpoint for memory not found              
INFO[0000] Loading containers: start.         

Mam wrażenie, że ma to związek z cgroup ... ale nie wiem nic o tej technologii (jeszcze) ...


Wygląda na to, że twoje pytanie spadło na podłogę i rozpadło się na kawałki. Złóż to dla nas.
Scott

@Scott - przepraszam ... mam nadzieję, że teraz jest lepiej ... dzięki za zwrócenie na to uwagi
hba

Odpowiedzi:


23

Okazało się, że muszę zainstalować cgroup-lite. To był strzał w ciemność, ale podążyłem za tą odpowiedzią


Wiesz, w pewnym momencie sam to odkryłem, a potem zapomniałem. Teraz znalazłem twoje pytanie, kiedy znów na nie wpadłem i przypomniałem sobie (i głosowałem).
0xC0000022L

W Debianie odpowiedni pakiet nazywa się cgroupfs-mount
Bass

1

Dodam tutaj kolejną odpowiedź dla osób widzących to w Debianie w 2020 r., Ponieważ moja odpowiedź na ten problem nie była obecna w żadnym z wyników wyszukiwania znalezionych podczas wyszukiwania w Google błędu „mountpoint for devices not found”.

Tło:

  • Debian 8.11 działający na Google Cloud Platform
  • Zainstalowano działającego Dockera 5 tygodni temu z działającymi dwoma kontenerami

Nagle zdałem sobie sprawę, że coś spowodowało rozbicie pojemników. Jedyną zdalnie prawdopodobną przyczyną, jaką mogłem wymyślić, było usunięcie folderu nadrzędnego na hoście, którego podfolder został zamapowany jako wolumin. Innym powodem może być zamontowanie dodatkowego urządzenia fizycznego.

W każdym razie wynik końcowy był taki, że próba uruchomienia dowolnego kontenera dokera spowodowała wyświetlenie komunikatu o błędzie widocznego w pytaniu („ mountpoint for devices not found”) i nie nastąpiło ponowne uruchomienie komputera (a tym samym aktualizacja jądra).

Kroki, które podjąłem w celu debugowania problemu, to:

  1. Sprawdzić dzienniki: journalctl -xn | less. Naprawdę nie zawierał zbyt wielu dodatkowych informacji
  2. Zatrzymaj demona Docker ( /etc/init.d/docker stop).
  3. Dodaj plik, w /etc/docker/daemon.jsonktórym znajdowała się jedyna treść{"debug": true}
  4. Spróbuj zrestartować demona dokera, aby zobaczyć, że nie działa
  5. Sprawdź dzienniki, które byłyby teraz wypełnione o wiele więcej informacji

Te cgrouppowiązane błędy doprowadziły do ​​odpowiedzi:

Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964631675Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964654637Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964667575Z" level=warning msg="Unable to find blkio cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964680057Z" level=warning msg="Unable to find cpuset cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964750643Z" level=warning msg="mountpoint for pids not found"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.980250151Z" level=debug msg="Cleaning up old mountid : start."
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: Error starting daemon: Devices cgroup isn't mounted

OK, coś o cgroupsmontażu. Doprowadziło mnie to do obejścia innego problemu grup roboczych, który można zastosować w tym przypadku, a jedynymi poleceniami, które wydawały się mieć wpływ, były

  1. /etc/init.d/docker stop
  2. cgroupfs-mount
  3. /etc/init.d/docker start

Teraz po ponownym uruchomieniu Dockera dzienniki nadal zawierały kilka wierszy błędów związanych z cgroup:

Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258571633Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258591020Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258937091Z" level=warning msg="mountpoint for pids not found"

Ale połowa z nich ( blkio, cpuset) zniknęła, a co ważniejsze, następny wiersz brzmiał:

Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.259420798Z" level=info msg="Loading containers: start."

I w końcu

Unit docker.socket has finished starting up.

Zasadniczo ponowne zamontowanie elementów grupy cg naprawiło problem. Nie ma potrzeby ponownego uruchamiania.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.