La creazione di thread non riesce con "Risorsa temporaneamente non disponibile" con kernel 4.3

Sto eseguendo un server docker su Arch Linux (kernel 4.3.3-2) con diversi container. Dal mio ultimo riavvio, sia il server docker sia i programmi casuali all'interno dei contenitori si bloccano con un messaggio sul fatto di non essere in grado di creare un thread o (meno spesso) di fork. Il messaggio di errore specifico varia a seconda del programma, ma la maggior parte sembra menzionare l'errore specifico Resource temporarily unavailable. Vedere alla fine di questo post per alcuni messaggi di errore di esempio.

Ora ci sono molte persone che hanno avuto questo messaggio di errore e molte risposte a loro. La cosa davvero frustrante è che tutti sembrano speculare su come risolvere il problema, ma nessuno sembra indicare come identificare quale delle tante possibili cause del problema sia presente.

Ho raccolto queste 5 possibili cause dell'errore e come verificare che non siano presenti sul mio sistema:

1. Esiste un limite a livello di sistema sul numero di thread configurati in /proc/sys/kernel/threads-max( sorgente ). Nel mio caso questo è impostato su 60613.
2. Ogni thread occupa dello spazio nello stack. Il limite della dimensione dello stack viene configurato utilizzando ulimit -s( origine ). Il limite per il mio guscio usato per essere 8192, ma ho aumentato che mettendo * soft stack 32768in /etc/security/limits.conf, quindi è ulimit -sora restituisce 32768. Ho anche aumentato per il processo finestra mobile mettendo LimitSTACK=33554432in /etc/systemd/system/docker.service( fonte , e verificato che il limite si applica, cercando in /proc/<pid of docker>/limitse eseguendo ulimit -sall'interno di un contenitore finestra mobile.
3. Ogni thread richiede un po 'di memoria. Un limite di memoria virtuale viene configurato mediante ulimit -v. Sul mio sistema è impostato su unlimitede l'80% dei miei 3 GB di memoria è gratuito.
4. Esiste un limite al numero di processi che utilizzano ulimit -u. I thread contano come processi in questo caso ( fonte ). Sul mio sistema, il limite è impostato su 30306, e per il demone docker e all'interno dei contenitori docker, il limite è 1048576. Il numero di thread attualmente in esecuzione può essere scoperto eseguendo ls -1d /proc/*/task/* | wc -lo eseguendo ps -elfT | wc -l( origine ). Sul mio sistema sono tra 700e 800.
5. Esiste un limite al numero di file aperti, che secondo alcune fonti è rilevante anche per la creazione di thread. Il limite viene configurato utilizzando ulimit -n. Sul mio sistema e all'interno della finestra mobile, il limite è impostato su 1048576. Il numero di file aperti può essere scoperto usando lsof | wc -l( sorgente ), sul mio sistema si tratta 30000.

Sembra che prima dell'ultimo riavvio stavo eseguendo il kernel 4.2.5-1, ora sto eseguendo 4.3.3-2. Il downgrade a 4.2.5-1 risolve tutti i problemi. Altri post che menzionano il problema sono questo e questo . Ho aperto una segnalazione di bug per Arch Linux .

Cosa è cambiato nel kernel che potrebbe causare questo?

Ecco alcuni esempi di messaggi di errore:

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

Il problema è causato dall'attributo TasksMaxsystemd. È stato introdotto in systemd 228 e utilizza il sottosistema pgroup cgroups, introdotto nel kernel 4.3 di Linux. Un limite di attività 512è quindi abilitato in systemd se il kernel 4.3 o più recente è in esecuzione. La funzione è annunciata qui ed è stata introdotta in questa richiesta pull e i valori predefiniti sono stati impostati da questa richiesta pull . Dopo aver aggiornato il mio kernel a 4.3, systemctl status dockervisualizza una Tasksriga:

# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/etc/systemd/system/docker.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2016-01-15 19:58:00 CET; 1min 52s ago
     Docs: https://docs.docker.com
 Main PID: 2770 (docker)
    Tasks: 502 (limit: 512)
   CGroup: /system.slice/docker.service

L'impostazione TasksMax=infinitynella [Service]sezione di docker.servicerisolve il problema. docker.serviceè di solito in /usr/share/systemd/system, ma può anche essere messo / copiato /etc/systemd/systemper evitare che venga sovrascritto dal gestore dei pacchetti.

Una richiesta pull è in aumento TasksMaxper i file systemd di esempio docker e un report di bug di Arch Linux sta cercando di ottenere lo stesso per il pacchetto. Sono in corso ulteriori discussioni sull'Arch Linux Forum e in una segnalazione di bug di Arch Linux relativa a lxc .

DefaultTasksMaxpuò essere utilizzato nella [Manager]sezione in /etc/systemd/system.conf(o /etc/systemd/user.confper i servizi gestiti dall'utente) per controllare il valore predefinito per TasksMax.

Systemd applica anche un limite per i programmi eseguiti da una shell di accesso. Questi sono predefiniti 4096per utente (saranno aumentati a12288 ) e sono configurati come UserTasksMaxnella [Login]sezione di /etc/systemd/logind.conf.

La risposta di cdauth è corretta, ma c'è un altro dettaglio da aggiungere.

Sul mio sistema Ubuntu 16.04 con systemd 229 e un kernel 4.3, un limite di pid 512 è stato imposto per impostazione predefinita sugli ambiti della sessione anche quando UserTasksMax era impostato sul nuovo valore predefinito aumentato di 12288. Quindi ogni ambito della sessione utente era limitato a 512 thread.

L'unico modo che ho trovato per rimuovere il limite era di set DefaultTasksMax=unlimitedin /etc/systemd/system.confe systemctl daemon-reexec(o riavvio).

È possibile verificare se ciò accade emettendo systemctl status, selezionando un ambito di sessione e cat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max.

Dopo aver letto questa discussione.

Questa soluzione ha funzionato per me: docker -d --exec-opt native.cgroupdriver=cgroupfs. L'ho effettivamente aggiunto a OPTIONSin /etc/sysconfig/docker...