Server Linux esaurito

31

Mi è stata posta questa domanda in due interviste consecutive, ma dopo alcune ricerche e controlli con vari amministratori di sistema non ho ricevuto una buona risposta. Mi chiedo se qualcuno mi può aiutare qui.

Un server ha esaurito lo spazio su disco. Si nota un file di registro molto grande e si determina che è sicuro da rimuovere. Si elimina il file ma il disco mostra ancora che è pieno. Cosa causerebbe questo e come lo rimedieresti? E come scopriresti quale processo sta scrivendo questo enorme file di registro?

— ewwhite
fonte

3

Devi parlare con amministratori di sistemi migliori. Questa è roba banale.

— womble

2

Triviale, ma la situazione e la domanda si presentano abbastanza spesso ...

— ewwhite

L'OP sarà in grado di accettarlo?

— ewwhite

5

Triviale o no, per qualcuno che non parla fluentemente * nix (ad esempio un amministratore principalmente di Windows) questa è una buona cosa da imparare.

— John Gardeniers,

56

Questa è una domanda di intervista comune e una situazione che si presenta in una varietà di ambienti di produzione.

Le voci della directory del file sono state eliminate, ma il processo di registrazione è ancora in esecuzione. Lo spazio non verrà recuperato dal sistema operativo fino alla chiusura di tutti gli handle di file (ad esempio, il processo è stato interrotto) e tutte le voci di directory rimosse. Per trovare il processo di scrittura nel file, è necessario utilizzare il lsofcomando.

L'altra parte della domanda a volte può essere "come si cancella un file su cui si sta scrivendo senza interrompere il processo?" Idealmente, dovresti "zero" o "troncare" il file di registro con qualcosa di simile : > /var/log/logfileinvece di eliminare il file.

— ewwhite
fonte

1

... o fuser.

— Steven lunedì

1

Espandendosi un po ': fino a quando tutti i riferimenti a un file sul disco svaniscono, quello spazio non può essere utilizzato da qualcos'altro. Ciò include gli handle di file. Ciò consente anche a questo trucco di funzionare: serverfault.com/questions/45237/link-to-a-specific-inode

— Jeff Ferland

1

Se hai no-clobberimpostato, prova:>| /var/log/logfile

— Belmin Fernandez

2

Faccio una variante di questa domanda in ogni intervista: "Stai ricevendo messaggi sul disco pieno. dfDice che sei fuori dallo spazio, dudice che ne stai a malapena usando. Che cosa lo sta causando e perché i due strumenti non sono d'accordo?"

— voretaq7,

Cosa fare se dopo > /var/log/filelo spazio su disco è ancora al 100%? Il file di registro sembra essere vuoto ... ma solo dopo aver riavviato il programma che scrive su questo file di registro lo spazio viene recuperato. C'è un modo per recuperare lo spazio su disco senza riavviare il programma?

— alemani,

14

C'è ancora un altro collegamento al file (hard link o handle di file aperto). L'eliminazione di un file elimina solo la voce della directory; i dati del file e l'inode restano in attesa fino a quando l'ultimo riferimento è stato rimosso.

È un po 'pratica comune per un servizio creare un file temporaneo ed eliminarlo immediatamente mantenendo aperto il file. Ciò crea un file su disco, ma garantisce che il file verrà eliminato se il processo termina in modo anomalo e impedisce anche che altri processi vengano calpestati accidentalmente sul file. MySQL lo fa, ad esempio, per tutte le sue tabelle temporanee su disco. I malware spesso usano tattiche simili per nascondere i suoi file.

Sotto Linux, puoi accedere comodamente a questi file eliminati come /proc/<pid>/fd/<filenumber>.

— tylerl
fonte

8

Non sono un amministratore di sistema, ma da quello che ho raccolto su Unix.SE, un sistema Linux non eliminerà effettivamente un file (contrassegna lo spazio come libero / riutilizzabile) dopo che è stato scollegato fino a quando tutti i descrittori di file che puntano a loro hanno stato chiuso. Quindi, per rispondere alla prima parte, lo spazio non è ancora libero perché un processo lo sta ancora leggendo. Per rispondere al secondo, puoi vedere con quale processo sta usando il file lsof.

— Kevin
fonte

2

Una risposta alternativa oltre all'ovvio link hard / risposta al file aperto: quel file è un file (molto) scarso come /var/log/lastlogsu RHEL che in realtà non occupava molto spazio. L'eliminazione ha avuto un impatto minimo, quindi è necessario esaminare il prossimo file più grande.

— Alexios
fonte

1

Se il processo di scrittura del file è root, verrà scritto nello spazio file riservato del superutente. Il file system ha questo spazio per mantenere operativo un sistema nel caso in cui un'attività dell'utente riempia il disco. Questo spazio (imho di default 5%) è invisibile a molti strumenti.

lsof può mostrarti quale processo ha bloccato il file, ergo ci sta scrivendo.

— Qualcuno
fonte

1

Puoi anche regolare questa percentuale di riserva usando tune2fs. Questo può essere un modo rapido per consentire al server di continuare a funzionare mentre si libera spazio su disco.

— sjbotha,

1

Oltre al file aperto da un processo, un secondo caso è quando si dispone di un file system che supporta snapshot come btrfso ZFS.

Ad esempio, si acquisisce un'istantanea con l'enorme file di registro esistente. Se elimini il file ora, eliminerai solo il delta. E il delta viene eliminato solo quando il file non è in uso.

Guarda anche:

Un terzo caso è quando si dispone di un file system che supporta la deduplicazione a livello di blocco e la maggior parte del file è identica a un altro file. Non mi aspetto che ciò accada per un registro a meno che non si disponga di un contenitore o di una VM che sta inviando i registri a un contenitore syslog o a una VM che condividono lo stesso FS in modo che il contenuto del registro sia identico.

— Mircea Vutcovici
fonte