Ho bisogno di assistenza per comprendere ciò che sono sicuro è un concetto fondamentale in Linux: il limite per i file aperti. In particolare, sono confuso sul perché i socket aperti possano contare per il numero totale di "file aperti" su un sistema.
Qualcuno può approfondire il motivo per cui? Capisco che questo probabilmente risale all'intero principio "tutto è un file" in Linux, ma ogni dettaglio aggiuntivo sarebbe apprezzato.
Risposte:
Il limite di "file aperti" non è in realtà solo per i file. È un limite al numero di handle del kernel che un singolo processo può utilizzare contemporaneamente. Storicamente, l'unica cosa che i programmi in genere aprivano molto erano i file, quindi questo è diventato noto come un limite al numero di file aperti. Esiste un limite per aiutare a impedire che i processi dicano, aprendo molti file e dimenticandosi accidentalmente di chiuderli, il che potrebbe causare problemi a livello di sistema.
Una connessione socket è anche un handle del kernel. Quindi si applicano gli stessi limiti per gli stessi motivi: è possibile che un processo apra le connessioni di rete e dimentichi di chiuderle.
Come notato nei commenti, gli handle del kernel sono tradizionalmente chiamati descrittori di file in sistemi simili a Unix.
read/ write, che è il cuore di ciò che significa essere un file.
shutdown(2)syscall su di loro, ma non sui file, e non puoi leggere da un socket usando cat- questo è il motivo netcatè stato creato. Direi che i socket (per fortuna) nei kernel simili a Unix si comportano come file in termini di I / O, ma la somiglianza finisce proprio lì. (Onestamente, mi piacerebbe anche avere notizie da qualcuno con esperienza del Piano 9, dato che ho sentito che hanno ottenuto l'unificazione di queste cose più lontano dei tradizionali unici).
La ragione per cui i descrittori di file uso di TCP / IP socket è che, quando l'interfaccia socket è stato progettato prima e implementato ( in BSD Unix, nel 1983 ), i suoi progettisti ha ritenuto che una connessione di rete è stato analogo a un file - è possibile read, writee closesia e che si adatterebbe perfettamente all'idea Unix di "tutto è un file".
Altre implementazioni dello stack di rete TCP / IP non si sono necessariamente integrate con il sottosistema di I / O dei file del loro sistema operativo, ad esempio MacTCP . Ma poiché l'interfaccia dei socket BSD era così popolare, anche queste altre implementazioni hanno scelto di replicare l'API socket con le sue funzioni simili a Unix, quindi hai ottenuto "descrittori di file", usati solo per la comunicazione TCP / IP, su sistemi che altrimenti non avrebbero hanno descrittori di file.
L'altra parte della tua domanda è: perché c'è un limite? È perché il modo più rapido per implementare una tabella di ricerca del descrittore di file è con un array. Storicamente, il limite è stato codificato nel kernel.
Ecco il codice in Unix versione 7 (1979) con un limite codificato di 20 descrittori di file per processo:
In confronto, Linux alloca dinamicamente lo spazio per la tabella descrittore di file di un processo. Il limite assoluto predefinito è 8192, ma puoi impostarlo come preferisci. Il mio sistema elenca 191072 in /proc/sys/fs/file-max.
alloc_fdtable()struct fdtable#define NR_FILE 8192Nonostante non ci siano più limiti assoluti in Linux, tuttavia non vogliamo far impazzire i programmi, quindi l'amministratore (o il pacchetto di distribuzione) generalmente imposta limiti di risorse. Dai un'occhiata /etc/security/limits.confo corri ulimit -n.
I file non sono solo file su disco o in memoria; sono flussi di dati, di cui questi sono solo due esempi.
Gli endpoint remoti sono un terzo esempio e interagisci con quelli che usano i socket.