Używam serwera dokującego na Arch Linux (jądro 4.3.3-2) z kilkoma kontenerami. Od czasu mojego ostatniego restartu zarówno serwer dokera, jak i losowe programy w kontenerach ulegają awarii z komunikatem o niemożności utworzenia wątku lub (rzadziej) rozwidlenia. Konkretny komunikat o błędzie różni się w zależności od programu, ale większość z nich wydaje się wspominać o konkretnym błędzie Resource temporarily unavailable
. Zobacz na końcu tego postu kilka przykładów komunikatów o błędach.
Teraz jest wiele osób, które otrzymały ten komunikat o błędzie i mnóstwo odpowiedzi na nie. Naprawdę frustrujące jest to, że wydaje się, że wszyscy spekulują, w jaki sposób problem można rozwiązać, ale nikt nie wskazuje, w jaki sposób określić, która z wielu możliwych przyczyn problemu jest obecna.
Zebrałem 5 możliwych przyczyn błędu i jak sprawdzić, czy nie występują w moim systemie:
- Istnieje ogólnosystemowy limit liczby wątków skonfigurowanych w
/proc/sys/kernel/threads-max
( źródłowym ). W moim przypadku jest to ustawione na60613
. - Każdy wątek zajmuje trochę miejsca na stosie. Limit wielkości stosu konfiguruje się za pomocą
ulimit -s
( źródła ). Limit dla mojej skorupy kiedyś8192
, ale zwiększyły się poprzez umieszczenie* soft stack 32768
na/etc/security/limits.conf
, więculimit -s
powraca32768
. Zwiększyłem go także dla procesu dokowania, wprowadzającLimitSTACK=33554432
do/etc/systemd/system/docker.service
( źródło , i zweryfikowałem, że limit ma zastosowanie, patrząc do/proc/<pid of docker>/limits
i uruchamiająculimit -s
wewnątrz kontenera dokera. - Każdy wątek zajmuje trochę pamięci. Limit pamięci wirtualnej konfiguruje się za pomocą
ulimit -v
. W moim systemie jest ustawiony naunlimited
, a 80% mojej 3 GB pamięci jest wolne. - Istnieje ograniczenie liczby używanych procesów
ulimit -u
. Wątki liczą się w tym przypadku jako procesy ( źródło ). W moim systemie limit jest ustawiony na30306
, a dla demona dokera i wewnątrz kontenerów dokowania limit jest1048576
. Liczbę aktualnie uruchomionych wątków można znaleźć, uruchamiającls -1d /proc/*/task/* | wc -l
lub uruchamiającps -elfT | wc -l
( źródło ). W moim systemie są między700
i800
. - Istnieje ograniczenie liczby otwartych plików, które według niektórych źródeł ma również znaczenie przy tworzeniu wątków. Limit jest konfigurowany za pomocą
ulimit -n
. W moim systemie i w oknie dokowanym limit jest ustawiony na1048576
. Liczbę otwartych plików można znaleźć za pomocąlsof | wc -l
( źródła ), w moim systemie to chodzi30000
.
Wygląda na to, że przed ostatnim ponownym uruchomieniem uruchomiłem jądro 4.2.5-1, teraz działam 4.3.3-2. Obniżenie wersji do 4.2.5-1 rozwiązuje wszystkie problemy. Inne posty wspominające o tym problemie to i to . Otworzyłem raport o błędzie dla Arch Linux .
Co zmieniło się w jądrze, co mogło to powodować?
Oto kilka przykładowych komunikatów o błędach:
Crash dump was written to: erl_crash.dump
Failed to create aux thread
Jan 07 14:37:25 edeltraud docker[30625]: runtime/cgo: pthread_create failed: Resource temporarily unavailable
dpkg: unrecoverable fatal error, aborting:
fork failed: Resource temporarily unavailable
E: Sub-process /usr/bin/dpkg returned an error code (2)
test -z "/usr/include" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/include"
/bin/sh: fork: retry: Resource temporarily unavailable
/usr/bin/install -c -m 644 popt.h '/tmp/lib32-popt/pkg/lib32-popt/usr/include'
test -z "/usr/share/man/man3" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/share/man/man3"
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: Resource temporarily unavailable
/bin/sh: fork: Resource temporarily unavailable
make[3]: *** [install-man3] Error 254
Jan 07 11:04:39 edeltraud docker[780]: time="2016-01-07T11:04:39.986684617+01:00" level=error msg="Error running container: [8] System error: fork/exec /proc/self/exe: resource temporarily unavailable"
[Wed Jan 06 23:20:33.701287 2016] [mpm_event:alert] [pid 217:tid 140325422335744] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
Odpowiedzi:
Problem jest spowodowany przez
TasksMax
atrybut systemd. Został wprowadzony w systemie 228 i korzysta z podsystemu pid cgroups, który został wprowadzony w jądrze Linuksa 4.3. Limit zadań512
jest więc włączony w systemd, jeśli jądro 4.3 lub nowsze jest uruchomione. Funkcja została ogłoszona tutaj i została wprowadzona w tym żądaniu ściągnięcia, a wartości domyślne zostały ustawione przez to żądanie ściągnięcia . Po aktualizacji mojego jądra do 4.3systemctl status docker
wyświetlaTasks
wiersz:Ustawienie
TasksMax=infinity
w[Service]
sekcjidocker.service
naprawia problem.docker.service
jest zwykle w/usr/share/systemd/system
, ale można go także umieścić / skopiować,/etc/systemd/system
aby uniknąć zastąpienia go przez menedżera pakietów.Prośba przyciąganie wzrasta
TasksMax
dla przykładu Döcker Systemd plików, a także raport o błędzie Arch Linux stara się osiągnąć to samo na opakowaniu. Trwa dodatkowa dyskusja na forum Arch Linux i w raporcie o błędach Arch Linux dotyczącym lxc .DefaultTasksMax
może być użyty w[Manager]
sekcji w/etc/systemd/system.conf
(lub/etc/systemd/user.conf
dla usług uruchamianych przez użytkownika) do kontrolowania wartości domyślnej dlaTasksMax
.Systemd stosuje również limit dla programów uruchamianych z powłoki logowania. Są one domyślnie ustawione
4096
na użytkownika (zostaną zwiększone do12288
) i są skonfigurowane jakUserTasksMax
w[Login]
sekcji/etc/systemd/logind.conf
.źródło
/lib/systemd/system/docker.service
w trakcie moich testów Debiana.systemctl set-property docker.service TasksMax=4096
, ustawi właściwość dla aktualnie uruchomionej usługi i zachowa ustawienie dla kolejnych restartów w odpowiednim miejscu dla danej instalacji dokera./etc/systemd/system/docker.service.d/50-TasksMax.conf
na Ubuntu 16), musisz uruchomićsystemctl daemon-reload
. Wykonaniesudo service docker restart
NIE zadziała.Odpowiedź cdauth jest poprawna, ale należy dodać jeszcze jeden szczegół.
W moim systemie Ubuntu 16.04 z jądrem systemd 229 i jądrem 4.3 domyślnie na zakresach sesji obowiązywał limit 512 pid, nawet gdy UserTasksMax ustawiono na nowy, zwiększony domyślny 12288. Tak więc zakres sesji użytkownika był ograniczony do 512 wątków.
Jedynym sposobem znalazłem się usunąć limit było stworzenie
DefaultTasksMax=unlimited
w/etc/systemd/system.conf
isystemctl daemon-reexec
(lub restarcie).Możesz sprawdzić, czy tak się dzieje, wydając
systemctl status
, wybierając zakres sesji icat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max
.źródło
@reboot lxc-autostart
do swojego crontaba, aby automatycznie uruchamiał je przy rozruchu, i nagle po restarcie dostajesz sparaliżowane pojemniki.Po przeczytaniu tego wątku.
To rozwiązanie pracował dla mnie
docker -d --exec-opt native.cgroupdriver=cgroupfs
. I rzeczywiście dodaje go doOPTIONS
in/etc/sysconfig/docker
...źródło