sistema inutilizzabile dopo make -j

11 risposte [Ultimo contenuto]
Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

Ciao,
Uso Debian 7.4 volevo ricompilare il kernel, ho dato i comandi:

~/linux-source-3.2$ scripts/config --disable DEBUG_INFO
~/linux-source-3.2$ make clean
~/linux-source-3.2$ time make -j >/dev/null

il sistema è diventato subito inutilizzabile e l'orologio sulla GUI si è fermato, dopo 2 ore circa di attività dei dischi lo schermo è diventato nero, dopo un hot reset all'avvio ha ricostruito il journal ext4 e il sistema è tornato funzionante. Il kernel su cui gira la macchina è quello di Debian non è ricompilato.
Ho ricostruito in VirtualBox 4.3.10 la macchina: 1GB di Ram, 1 processore, 4 HD da 8GB, video 128MB ...
e configurato l'installazione: Raid5 3active 1spare, lvm 2 volumi uno per l'installazione uno per la swap. Questi i dettagli della macchina in VirtualBox:
~$ cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ld0-lv1 /               ext4    errors=remount-ro 0       1
/dev/mapper/ld0-swap none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
 
~$ free
             total       used       free     shared    buffers     cached
Mem:       1027012     554116     472896          0      26684     305804
-/+ buffers/cache:     221628     805384
Swap:      5242876          0    5242876
 
~$ cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sda1[0] sdd1[3](S) sdc1[2] sdb1[1]
      16763904 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
 
unused devices: <none>

Il freeze si ripresenta, è riproducibile, volevo un parere se devo aprire un bug report al kernel Debian.

Ciao, Franco

Ritratto di mcortese
mcortese
(Moderatore)
Offline
Moderatore
Iscritto: 27/02/2009
Messaggi: 2544

Credo sia normale dando un make senza nessun numero dopo -j, o no?

Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

No, non è normale che un programma faccia un freeze del sistema, l'opzione -j può essere data anche senza un numero.
Aggiorno la situazione, avviando la macchina virtuale in rescue mode, quindi senza X server la compilazione procede regolarmente per molto tempo poi appare la schermata allegata, se la avvio in un terminale (Gnome o KDE) il sistema virtuale va in freeze, se disabilito la swap nella macchina virtuale (Gnome) X crasha poco dopo iniziata la compilazione. Che fare? Plain Face

Attached images:

Ciao, Franco

Ritratto di homeless
homeless
(Guru)
Offline
Guru
Iscritto: 21/10/2011
Messaggi: 1099

Aumenta (di molto) la ram a disposizione del sistema prima di avviare la compilazione del kernel.

Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

Infatti, la macchina virtuale va poi in freeze con la schermata allegata e poi dopo un reset risincronizza il RAID. Ma quello che mi chiedo: non va segnalato che basta un make -j per mandare in freeze il PC (non solo quello virtuale ma anche quello fisico che ha 8Gb di ram)?
Dimenticavo l'architettura è amd64.

Attached images:

Ciao, Franco

Ritratto di homeless
homeless
(Guru)
Offline
Guru
Iscritto: 21/10/2011
Messaggi: 1099

La schermata che hai inviato indica che il kernel sta terminando i processi in esecuzione perché essi (di compilazione del kernel ?) hanno completamente saturato le risorse in termini di memoria RAM del tuo sistema virtuale. L'opzione del comando make non ha nulla a che vedere con gli errori che stai riferendo. Non devi stupirti che il sistema si blocchi se tenti di compilare il kernel con una macchina che non dispone delle risorse sufficienti.

Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

homeless ha scritto:

La schermata che hai inviato indica che il kernel sta terminando i processi in esecuzione perché essi (di compilazione del kernel ?) hanno completamente saturato le risorse in termini di memoria RAM del tuo sistema virtuale. L'opzione del comando make non ha nulla a che vedere con gli errori che stai riferendo.


Eppure ti garantisco che se ometto l'opzione -j il comando make viene eseguito senza problemi, l'output del comando time restituisce circa 7 minuti.
homeless ha scritto:

Non devi stupirti che il sistema si blocchi se tenti di compilare il kernel con una macchina che non dispone delle risorse sufficienti.


Bhe' se dici così, allora... non è per insistere ma credevo che il kernel avesse dei meccanismi di protezione per situazioni che inducano volutamente un crash in altre parole pensavo impossibile per un comando dato in user space determinare un freeze senza che questo sia da interpretare come un bug di quei meccanismi. E' possibile che gli dia fastidio il fatto che è eseguito in un volume logico di un device RAID5 software? (vedi primo post)
E' hardware nuovo, provo a fare un memtest che non siano problemi di ram.

P.S.
Auguroni per il tuo millesimo post Party Big Grin

Ciao, Franco

Ritratto di mcortese
mcortese
(Moderatore)
Offline
Moderatore
Iscritto: 27/02/2009
Messaggi: 2544

È possibile imporre dei limiti alle risorse che un utente può usare (vedi ulimit), ma di solito nessuno si prende la briga di imporli. Giusto o sbagliato che sia, la tradizione UNIX vuole che un utente che deve, ad esempio, lanciare un lavoro CPU-intensive usi nice per autolimitare la priorità dei propri processi.

L'esaurimento della memoria, poi, merita un discorso a parte. Per ragioni storiche, Linux usa una pratica depravata chiamata overcommit: il kernel risponde sempre sì a ogni allocazione di memoria da parte dei processi, anche se non ne ha abbastanza libera, perché sa che statisticamente i processi non usano tutta la memoria che chiedono (questo, a sua volta deriva dall'uso massiccio del fork() di origine UNIX).

Tutto ciò è del tutto analogo all'overbooking delle compagnie aeree, le quali vendono più biglietti dei posti disponibili perché sanno che, statisticamente, non tutti i passeggeri si presenteranno. O alla pratica delle banche che tengono nelle casse meno liquidità della somma dei depositi dei loro correntisti.

Tutto funziona bene in tempi normali, ma precipita in condizioni critiche: se tutti i viaggiatori si presentano al checkin, se tutti i clienti si presentano a batter cassa lo stesso giorno, se tutti i processi reclamano la memoria che hanno allocato e non ce n'è più... allora si devono prendere misure drastiche: qualcuno viene lasciato a terra, una banca rischia il fallimento, e il kernel può andare in palla (thrashing) o iniziare a uccidere processi a caso (OOM killer).

Decisamente, quello dell'esaurimento della memoria è un problema tutt'altro che risolto per Linux.

Infine, per completare il discorso sull'esaurimento delle risorse, bisogna dire che tutti i meccanismi studiati e messi in pratica fino all'altro ieri sono focalizzati su sistemi a sé stanti, non macchine virtuali che girano in altre macchine: oggi, oltre ai processi che si contendono le risorse dall'interno, ci sono le altre macchine virtuali che le contendono dall'esterno. In fondo, non sono così stupito che un semplice fork bomb come "make -j" possa mettere in ginocchio un sistema che evidentemente non è ancora del tutto pronto per la virtualizzazione (almeno non in casi critici).

Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

Ho messo "Risolto" troppo presto. Ho provato con ulimit che è un comando bash built-in a limitare la memoria e il numero dei processi ma il sistema continua ad andare in freeze dopo un make -j e siccome non accetto che il kernel abbia questo comportamento da un comando dato un semplice utente ho cercato tra i pacchetti della distribuzione se ce ne fossero che ovvino a questo problema ho trovato linux-patch-grsecurity2 e leggendo la descrizione del pacchetto sembra mutuamente esclusivo a SELinux se ho capito bene (vedi LSM). Allora domande:

  1. sto sbagliando qlcs con la sintassi di ulimit, mi potete suggerire una sintassi da provare?
  2. anche SELinux risolve come grsecurity il problema dei fork eccessivi?
  3. è da preferire grsecurity per migliori performance (vedi qui)?

Grazie veramente per le risposte.

Ciao, Franco

Ritratto di mcortese
mcortese
(Moderatore)
Offline
Moderatore
Iscritto: 27/02/2009
Messaggi: 2544

frank67 ha scritto:

sto sbagliando qlcs con la sintassi di ulimit, mi potete suggerire una sintassi da provare?

Direi che la sintassi è la seguente
ulimit -u 200
dove 200 è il massimo numero di processi che vuoi che il tuo utente possa lanciare, ma il numero giusto lo devi trovare tu.
A prescindere da tutto il resto, credo comunque che una buona abitudine, purtroppo mai consigliata da nessuno, sia quella di lanciare ogni compilazione con nice. Se il sistema è scarico, la compilazione userà comunque tutta la CPU disponibile, ma se ci sono altri processi in contemporanea, questi avranno la precedenza e non saranno disturbati più di tanto dalla compilazione.

Su grsecurity non so nulla, quindi non posso aiutarti.

E non so neanche niente di virtualizzazione, ma se un processo impazzito dentro la macchina guest fa piantare la macchina host, io credo ci sia qualcosa di sbagliato nel meccanismo di virtualizzazione, a prescindere dal fatto che giri un kernel Linux, Windows, o che altro. Ci saranno ben delle "quote" (di memoria, di CPU, di qualsiasi risorsa) dedicate a ciascun guest, no? Non posso immaginare che se affitto una macchina virtuale su Aruba, qualsiasi mio "coinquilino" possa consumare il 100% delle risorse.

Ritratto di frank67
frank67
(Monster)
Offline
Monster
Iscritto: 10/07/2013
Messaggi: 473

mcortese ha scritto:

E non so neanche niente di virtualizzazione, ma se un processo impazzito dentro la macchina guest fa piantare la macchina host, io credo ci sia qualcosa di sbagliato nel meccanismo di virtualizzazione


No, no mi si piantava il PC allora ho ricostruito in VirtualBox la configurazione del PC con device RAID lvm2 etc.. dopo aver rischiato di perdere il RAID sul PC a causa di un hibernate evito di sperimentare cose che possino comprometterne la stabilità. Si pianta solo la macchina virtuale e dal menù VirtualBox gli do un reset.
mcortese ha scritto:

a prescindere dal fatto che giri un kernel Linux, Windows, o che altro. Ci saranno ben delle "quote" (di memoria, di CPU, di qualsiasi risorsa) dedicate a ciascun guest, no?


Si che vanno ad esaurirsi sia nel PC fisico che nella macchina virtuale senza meccanismi di protezione come ulimit o grsecurity suppongo Confused
mcortese ha scritto:

Su grsecurity non so nulla, quindi non posso aiutarti.


Peccato dalla descrizione sembrava proprio indicato Crying
mcortese ha scritto:

Direi che la sintassi è la seguente

ulimit -u 200
dove 200 è il massimo numero di processi che vuoi che il tuo utente possa lanciare, ma il numero giusto lo devi trovare tu.


Avevo provato anch'io ma non avevo aspettato abbastanza tempo con 512 la macchina virtuale non si pianta, sembra in freeze ma poi si riprende, con 200 il make -j si interrompe subito e il sistema è OK Big Grin
Ma per fare in modo che ulimit sia settato solo per gli utenti e non per root senza che questi possano modificarlo come faccio? Cambio l'owner in root di ~/.bashrc e lo metto solo leggibile a tutti? C'è una via più "elegante"?

Ciao, Franco