Spazio su disco insufficiente, qual è l'origine?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

mentre in preda al panico alla ricerca di risposte dopo quelle che sembravano età l'uso è diminuito

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

Non ho cancellato nulla finora e il e ora che sto scrivendo questo è tornato a

/dev/sda1             220G   12G  197G   6% /

Cos'è successo?? Come posso indagare sulla causa e impostare le cose in modo che non accada di nuovo, impedisco che ciò accada di nuovo

Durante il periodo di utilizzo del massaggio ho scoperto che la dimensione della cartella / var era costante a 1,8 concerti ma non ero in grado di controllare tutte le cartelle

modifica passata a

/dev/sda1             220G   18G  192G   9% /

* aggiornamento 2 * Risale di nuovo

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

E controllando il comando mi è stato dato

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

notare 3.3G per /

Penso che tu abbia qualcosa che scrive su un file che è stato cancellato dall'unità ma non ancora chiuso dall'applicazione / server, quindi lo spazio rimane allocato sul disco ma non può essere visto da duquando il file è stato rimosso dal filesystem. Il lsofprogramma elenca i processi con file aperti. Se avessi montato più filesystem e il numero non fluttuasse così tanto, allora avrei suggerito di avere un filesystem montato su una directory che non era vuota (anche se potresti provare ad umount /var/lib/ureadahead/debugfsassicurarti che la directory sia vuota e non c'è un mucchio di spazzatura scritto nella directory nascosta sotto quel mountpoint).

In questo caso, dovresti trovarli facilmente con sudo lsof | grep deleted. lsofinclude (deleted)nell'ultima colonna se un file è stato eliminato mentre un processo lo ha ancora aperto. La prima colonna è il nome del comando, la seconda colonna è il PID. È possibile ottenere uno sguardo più dettagliato al comando usando psad esempio ps auxww | grep PID, oppure ps auxwwf | less -Svedere l'elenco dei processi in modalità "foresta" in modo da poter vedere da quale processo proviene il PID. Dopo aver rintracciato i processi che contengono file giganti aperti, è possibile interromperlo per liberare spazio sull'unità, quindi capire come risolverlo per chiudere correttamente il file. La causa abituale di ciò è uno script logrotate che rinomina / elimina i file di registro ma non notifica all'applicazione che lo ha fatto (tramite un segnale appropriato conkill o riavviando l'applicazione), quindi l'applicazione continua a tenere aperto il vecchio file di registro.

Correre

du -h --max-depth=1 /

E dovrebbe dare un quadro più chiaro. Se va e viene, sembra che i file temporanei vengano creati e quindi non eliminati una volta terminati, fino a quando qualunque processo lo causa. Quale sistema operativo esegue questo server e esegue qualcosa in particolare?

Sembra che il problema sia /var/lib/ureadahead/debugfs. Sembra che questo sia un problema noto, ecco un link a ubuntuforums con maggiori informazioni http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . Il tl; dr sembra essere aggiornamento e aggiornamento sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, quindi riavviare. Certo, presumo che tu stia eseguendo 10.04.

La mia ipotesi è i file di registro; Ho avuto così tanti avvisi "deprecati" di PHP 5.3 nei miei log di Apache su un server dev che non stavo davvero prestando attenzione a che ha consumato tutti gli 8 GB di spazio sulla mia partizione var (come barra laterale del problema: dovresti sempre mettere / var su una partizione separata in modo che la partizione di root a corto di spazio possa causare problemi di instabilità del sistema).

Se lo spazio è stato consumato molto rapidamente (non nei secoli), probabilmente è solo l'allocazione dei file.

La causa potrebbe essere un enorme scambio o file temporanei per alcune applicazioni, che vengono svuotati dopo il suo processo.

Fai du --max-length=1quando lo spazio è molto consumato.

Se pensi che la tua cartella principale stia prendendo troppo (3,3 GB) prova ll -a / e pubblica i risultati.

Sembra che /var/lib/ureadahead/debugfspossa essere un'aringa rossa. Ecco perché...

Mentre /var/lib/ureadahead/debugfsesiste in /etc/mtab, non si trova in /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

Il dfcomando sembra riportare esattamente la stessa cosa per /var/lib/ureadahead/debugfse/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Creazione di un file da 1 GB in /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Mostra le dimensioni riportate in entrambi i punti:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Quindi, sembra che il /var/lib/ureadahead/debugfsdispositivo sia un'aringa rossa in quanto rispecchia solo le statistiche /. Se stai esaurendo lo spazio, è dovuto a qualcosa che riempie il tuo filesystem di root. Vorrei prima controllare il tuo / var / log.

Il problema veniva avviato da un'attività cron che eseguiva un comando CLI php ogni minuto. Il codice PHP sembrava bloccato in una sorta di ciclo di follia di errori rilevati e di enormi quantità di dati di debug che crescevano alla velocità del processore.

Dato che il codice php in esecuzione impiegava più di un minuto a non considerare il lavoro svolto, continuava a essere eseguito ancora e ancora aumentando la velocità di crescita dei dati (temporanei?).

La stessa attività è stata eseguita per quasi un mese senza problemi, quindi non era nella mia mente come causa.

La cosa strana è che lo script php imposta manualmente il tempo massimo di esecuzione

Ho controllato php.ini per indizi

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

Dice che i valori sono hardcoded su illimitati per la CLI! O_o