Riempimento del filesystem di root, nessun file di grandi dimensioni

Quindi sono un nuovissimo amministratore di sistema, appena uscito da scuola e facendo il mio internato. L'unico problema è che sono l'unico amministratore di sistema nel posto e nessuno a mostrarmi il lavoro. Ad ogni modo, è una società molto piccola, un server CentOs con quella configurazione:

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3             184G  140G   35G  81% /

tmpfs                 2.3G     0  2.3G   0% /lib/init/rw

udev                  2.3G  212K  2.3G   1% /dev

tmpfs                 2.3G     0  2.3G   0% /dev/shm

/dev/sda1             4.6G  156M  4.2G   4% /boot

/dev/sda4              33G  176M   31G   1% /tmp

/dev/sdb1             1.8T  1.8T     0 100% /media/backupInterne

/dev/sdd1             917G  470G  401G  54% /media/Data

Sono arrivato qui solo pochi giorni fa e ho notato subito l'intero disco e sto lavorando per risolvere il problema. L'altro mio problema qui è sda3 ora all'81%. 4 giorni fa, era al 79%.

Ho corso il du -ah | ordina il comando -rh nella directory / root, non c'è niente di speciale. L'ho fatto in pochi giorni, poiché la partizione sda3 si sta riempiendo rapidamente, senza grandi differenze che potrebbero spiegare perché sta crescendo.

molte grazie

linux filesystems mount

— littleadmin
fonte

La mia ipotesi sarebbe la crescita dei tronchi perché sdb1è piena, ma vedremo quanto /varè grande ... da cosa ottieni du -sh /*?

— Shane Madden,

Se vuoi vedere quali file sono stati caricati, puoi usare find-mtime n [smhdw]. Sospetto che Shane abbia ragione. Parte di esso potrebbe essere costituita dai file di registro che lamentano l'intero volume sdb1. Il comando potrebbe essere simile al seguente: find / -type f -mtime 1d -print Se la tua ricerca supporta, --exclude-dir=allora vuoi escludere / dev e / proc.

— Hennes,

/ var è 1,7 G e la sua dimensione si è mossa appena negli ultimi giorni, è stata la mia prima idea di verificarlo.

— Eseguo

Dal momento che hai scritto che sei un nuovo amministratore, vorrei sottolineare uno dei motivi più comuni di crescente utilizzo del disco. Log files. Se si apre un file (ad es. Il registro da un server Web) e successivamente si elimina quel file, il file continuerà a utilizzare lo spazio su disco fino a quando il programma non chiude il suo handle a quel file. Quest'ultimo a volte viene risolto inviando una registrazione ( kill -1 PID-> rileggi il file di configurazione e riavvia per molti demoni) o dall'ascia contundente del riavvio.

— Hennes,

In caso di crescita dei tronchi, potrebbe stabilizzarsi in pochi giorni quando inizia la rotazione settimanale dei tronchi.

— ptman

Risposte:

Ecco cosa uso nel cercare di capire problemi come questo.

du -s `ls -a | egrep -v '\.\.'` | sort -nr | head

Ti mostrerà l'utilizzo per directory / file nella directory corrente. Da lì scendi nelle directory secondarie fino a trovare qualcosa di ovvio.

Avere tutto in un'unica grande partizione può rendere difficile la diagnosi di problemi come questo. Un altro approccio da provare è l'utilizzo

lsof

per vedere quali file sono aperti dai vari processi e vedere se riesci a trovare alcuni indizi. Questo è molto incostante.

— Fred il Magic Wonder Dog
fonte

+1 per menzionare lsof. Questo strumento sarà utile per un nuovo amministratore (anche se potrebbe essere toccato e risolto per questo problema).

— Hennes,

l'utilizzo per directory / file mi dà 5 risultati, nessuno dei quali oltre i 600k.

— littleadmin,

Sembra un problema simile che ho sempre con i file eliminati (ma il riferimento è ancora lì).

Se stiamo parlando di un sistema Linux, esegui:

lsof + L1

Questo sarà un elenco di file eliminati, ma sono ancora aperti e utilizzati da qualcosa. La chiave è ottenere tutto ciò che ha il filehandle aperto per rilasciarlo.

— Eirik Toft
fonte

Purtroppo non ha fornito alcun file che potesse spiegare la perdita di spazio che sta accadendo ogni giorno. grazie

— littleadmin il

È possibile che qualcosa stia scrivendo in una directory che viene poi montata su un filesystem? Una volta ho avuto gigabyte di inspiegabili acconciature. Anche se questo non dovrebbe mai essere possibile, sono stato in grado di dimostrare che può accadere.

— Eirik Toft,

Sto pensando anche a qualcosa del genere, ma come è potuto accadere? E come posso verificarlo senza smontare tutto?

— littleadmin,

Alla fine ho capito cosa stava succedendo. Uno dei punti montati non si montava correttamente e quindi faceva il backup direttamente su sda3.

Grazie a tutti per l'aiuto

— littleadmin
fonte