Não há espaço no erro do dispositivo, mas o df reporta como mais espaço disponível

Question

Minhas sessões de PHP no meu servidor web Debian usando Apache2 com mod_php parecem estar falhando aleatoriamente, dizendo que não há espaço para escrevê-las:

sudo tail -60 /var/log/apache2/error.log
[Fri Jan 30 15:55:35 2015] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  session_start() [<a href='function.session-start'>function.session-start</a>]: open(/tmp/sess_555555555555555555, O_RDWR) failed: No space left on device (28) in /path/to-first-session-use/core/bootstrap.php on line 18

Quando tento:

ls /tmp

Ele fica pendurado para sempre, então isso é ruim.

Mas quando eu verificar o espaço livre, e verificar se o uso do inode é razoável ...

$ df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             150G  121G   22G  85% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                   10M   16K   10M   1% /dev
tmpfs                 2.0G  4.0K  2.0G   1% /dev/shm

$ df -i

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1            19922944 11143605 8779339   56% /
tmpfs                 513524       4  513520    1% /lib/init/rw
udev                  513524     135  513389    1% /dev
tmpfs                 513524       3  513521    1% /dev/shm

Os números parecem bem. Claro, 85% é mais do que eu gostaria, mas não é 99% nem nada.

Eu suspeitava que era um problema devido a não reinicializar a máquina por 5 anos e talvez a criação de muitos arquivos pequenos, mas as informações do inode que estou começando a contradizer. Onde devo investigar em vez disso?

Editar:

ls -l /

drwxrwxrwt   4 root root 692M Feb  1 11:09 tmp/
drwxr-xr-x  10 root root 4.0K Jan  1  2013 usr/
drwxr-xr-x  14 root root 4.0K Oct  7  2010 var/
...etc

    

Answer 1

Pode ser que o diretório /tmp/ esteja cheio de sessões antigas do PHP que não estão sendo limpas; significando que a origem dos problemas pode estar isolada no diretório /tmp/ . Se esse for o caso, eu apenas removerei todos os arquivos /tmp/sess_* . Primeiro, liste todos os arquivos sess_* como este:

ls -la /tmp/sess_*

Ou você pode contar com wc da seguinte forma:

ls -la /tmp/sess_* | wc -l

Agora, uma vez que você receba alguma confirmação, há um número insano de arquivos, vá em frente e execute este comando para excluir os arquivos /tmp/sess_* :

sudo rm -rf /tmp/sess_*

E os arquivos da sessão efêmera serão surpreendidos.

Mas outra forma bruta - mas relativamente segura - de lidar com isso é afastar o diretório /tmp , recriar o diretório /tmp e reinicializar o servidor.

Como o diretório /tmp é basicamente uma caneta de codificação para material em cache, não há nada válido que deva estar lá. Então, meu melhor conselho é executar o seguinte comando para remover o & rebuidl o diretório /tmp .

rm -rf /tmp && mkdir /tmp/ && chown root:root /tmp && chmod 1777 /tmp

Agora que um liner é basicamente uma lista de comandos shell conectados por && que primeiro excluirá /tmp , recriará /tmp , alterará a propriedade de /tmp de volta para root:root e, em seguida, definirá permissões adequadas para o diretório /tmp . Se você quiser, pode executar cada comando, um por um, se se sentir mais seguro ao fazer isso.

sudo rm -rf /tmp 
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp

Depois disso, recomendo a reinicialização do servidor. As coisas devem estar calmas limpas novamente.

    

Answer 2

Às vezes, o sistema de arquivos danificado pode causar efeitos como esse - por exemplo, quando o diretório / tmp está danificado. Ou - quando há muitos arquivos.

Para correção "rápida":

mv /tmp /tmp.xxx
mkdir /tmp
chmod a+rwxt /tmp

Se isso ajudar - tente reiniciar o sistema e fsck sistema de arquivos raiz. Se estiver ok - apenas remova o diretório /tmp.xxx.

Outra possibilidade é - quando / tmp é a partição "other" ou tmpfs (vista no linux vservers) - mas ela não é mostrada pelo df (porque df pega lista de partições do arquivo / etc / mtab que algumas vezes não está correto). Tente verificar o espaço em disco diretamente no tmp pelo comando:

df /tmp
df -i /tmp

Outra opção que geralmente ajuda com as sessões - usando outro mecanismo de sessão. Se você tiver muitas sessões temporárias, o que não precisa ser muito persistente - eu recomendaria o uso do memcache para armazenamento de sessão. Configuração muito simples - você deve instalar o php-memcache, memcached e depois no php.conf configure:

session.save_handler = memcache
session.save_path="tcp://server:port?persistent=1&weight=1&timeout=1&retry_interval=15"

Em seguida, as sessões serão armazenadas no memcache até o tamanho definido. sobre ele - o mais antigo será removido automaticamente.

    

Answer 3

Para mim, alterar fs.inotify.max_user_watches resolveu o problema.

root@grostruc:/# service ssh restart
Error: No space left on device
root@grostruc:/# sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 65536
root@grostruc:/# sysctl fs.inotify.max_user_watches=262144
fs.inotify.max_user_watches = 262144
root@grostruc:/# service ssh restart

Corrija o valor alterado em /etc/sysctl.conf