Squid respondendo sem formatação

[g4p]

Boa tarde,

Pessoal, o Squid ta respondendo sem formatação CSS. É como se ele estivesse mandando apenas o HTML. As vezes nem abre. Tava funcionando tudo certinho. De repente, parou de responder corretamente.

O que pode ser?

[zekkerj]

Provavelmente vc bloqueou o acesso a arquivos CSS. Confirme isso nos logs do sistema (/var/log/squid/access.log).

[g4p]

Bloquiei não.

Porém, ao acessar o servidor, mostra no MOTD que a raiz ("/") está 100% de uso do espaço (255gb). Estranho que não faz sentido. Esse é um servidor de Backup. Tem apenas o Sarg e OCS Server nele. Não faz sentido está cheio, o backup é feito em um HD separado (externo).

O que pode ser? o.O

[zekkerj]

Claro que faz sentido, todo sistema precisa de manutenção regular. O primeiro sintoma da falta dela é esse: sistemas de arquivos lotam, e programas param de funcionar direito devido a isso.
Corrija, depois retorne aqui.

[g4p]

Existe alguma forma de saber aonde está o diretório que tanto ocupa espaço na raiz?

[Arthur Bernardes]

Acho que o comando df -h pode lhe dar essa resposta.

[g4p]

editora@bkp-editora:~$ df -h
Sist. Arq.       Tam  Usad Dispon. Uso% Montado em
/dev/sda1       226G  226G       0 100% /
udev            1,9G  8,0K    1,9G   1% /dev
tmpfs           771M  9,7M    762M   2% /run
none            5,0M     0    5,0M   0% /run/lock
none            1,9G     0    1,9G   0% /run/shm
none            100M     0    100M   0% /run/user
overflow        1,0M     0    1,0M   0% /tmp
/dev/sdb1       2,7T  1,7T    971G  63% /srv/Storage1

Porém, isso eu já sei.

Gostaria saber se existe alguma forma de identificar o diretório que ta comendo o espaço todo.

[zekkerj]

cd /
du -smx * | sort -n

Senta que vai demorar um bocado.
PS: Vc não tem o /var numa partição separada, certo? Nesse caso, pode adiantar o serviço e fazer a busca em /var/log, em vez de fazer na raiz.

[g4p]

O que faz esse du -smx?

[g4p]

editora@bkp-editora:/$ sudo du -smx * | sort -n
[sudo] password for editora:
Sorry, try again.
[sudo] password for editora:
du: impossível acessar "proc/7818/task/7818/fd/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/7818/task/7818/fdinfo/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/7818/fd/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/7818/fdinfo/3": Arquivo ou diretório não encontrado
0   initrd.img
0   initrd.img.old
0   proc
0   sys
0   tmp
0   vmlinuz
0   vmlinuz.old
1   dev
1   home
1   lib64
1   lost+found
1   media
1   mnt
1   opt
1   selinux
1   srv
6   etc
9   bin
10   run
11   sbin
27   root
29   boot
200   lib
782   usr
3444   var

[g4p]

editora@bkp-editora:/var/log$ sudo du -smx * | sort -n
1   ConsoleKit
1   landscape

[zekkerj]

Como eu pensava... o diretório com maior ocupação é o "/var" (3.444MB). Muito provavelmente o maior diretório dentro dele será o "/var/log" (o comando "du -smx /var | sort -n" irá confirmar isso).

Olhe dentro do diretório /var, veja se não há arquivos de log antigos que possam ser apagados.

[g4p]

Retornou apenas isto:

editora@bkp-editora:~$ sudo du -smx /var | sort -n
[sudo] password for editora:
3444   /var
editora@bkp-editora:~$

[zekkerj]

Esquece, o mais provável é que seja mesmo o diretório /var/log. Procure por arquivos grandes nele, ou por backups dos arquivos de log. Estes backups têm extensões ".1", ".2", etc.

[g4p]

editora@bkp-editora:/var/log$ ls -la
total 16
drwxr-xr-x  4 root root 4096 Jul  1 11:32 .
drwxr-xr-x 14 root root 4096 Jun 30 13:22 ..
drwxr-xr-x  2 root root 4096 Jul  1 06:33 ConsoleKit
drwxr-xr-x  2 root root 4096 Jul  1 11:32 landscape

Só tem essas duas pastas.

editora@bkp-editora:/var/log$ cd ConsoleKit/
editora@bkp-editora:/var/log/ConsoleKit$ ls
history  history.1
editora@bkp-editora:/var/log/ConsoleKit$ cd ../landscape/;ls
sysinfo.log
editora@bkp-editora:/var/log/landscape$