Fórum Ubuntu Linux - PT
Suporte Técnico => Internet, Redes e Segurança => Tópico iniciado por: g4p em 30 de Junho de 2014, 12:01
-
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?
-
Provavelmente vc bloqueou o acesso a arquivos CSS. Confirme isso nos logs do sistema (/var/log/squid/access.log).
-
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
-
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.
-
Existe alguma forma de saber aonde está o diretório que tanto ocupa espaço na raiz?
-
Acho que o comando df -h pode lhe dar essa resposta.
-
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.
-
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.
-
O que faz esse du -smx?
-
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
-
editora@bkp-editora:/var/log$ sudo du -smx * | sort -n
1 ConsoleKit
1 landscape
-
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.
-
Retornou apenas isto:
editora@bkp-editora:~$ sudo du -smx /var | sort -n
[sudo] password for editora:
3444 /var
editora@bkp-editora:~$
-
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.
-
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$
-
http://ubuntuforum-pt.org/index.php/topic,93678.msg514691.html#msg514691
http://ubuntuforum-pt.org/index.php/topic,71838.0.html
-
Seu squid está configurado para gravar em "/var/cache/squid"? Se estiver, diminua o tamanho do cache em disco, remova as pastas, e depois as recrie com o comando "sudo squid -Z".
-
editora@bkp-editora:/var/cache$ ls -la
total 40
drwxr-xr-x 10 root root 4096 Fev 7 06:52 .
drwxr-xr-x 14 root root 4096 Jun 30 13:22 ..
drwxr-xr-x 3 www-data www-data 4096 Fev 6 09:18 apache2
drwxr-xr-x 3 root root 4096 Jul 2 06:41 apt
drwxr-xr-x 3 root root 4096 Fev 7 06:52 apt-xapian-index
drwxr-xr-x 2 root root 4096 Mai 18 00:40 debconf
drwx------ 2 root root 4096 Mai 18 00:40 ldconfig
drwxr-sr-x 34 man root 4096 Jul 2 06:42 man
drwxr-xr-x 2 root root 4096 Dez 13 2011 pppconfig
drwxr-xr-x 3 root root 4096 Jul 2 15:30 samba
Por um momento achei que fosse isso, mas nem existe a pasta.
Que coisa, ein?
-
tenta pesquisar então qual é a pasta que está te comendo o espaço livre.
cd /var ; du -smx * | sort -n
Programe-se também pra separar o diretório /var em uma partição própria, nas próximas instalações de servidor que vc fizer.
-
Nas próximas vou fazer isso..
Aqui:
editora@bkp-editora:/var/cache$ cd /var ; du -smx * | sort -n
du: impossível ler diretório "cache/ldconfig": Permissão negada
du: impossível ler diretório "lib/sudo": Permissão negada
du: impossível ler diretório "lib/polkit-1": Permissão negada
du: impossível ler diretório "lib/php5": Permissão negada
du: impossível ler diretório "lib/mysql": Permissão negada
du: impossível ler diretório "spool/cron/atjobs": Permissão negada
du: impossível ler diretório "spool/cron/atspool": Permissão negada
du: impossível ler diretório "spool/cron/crontabs": Permissão negada
0 lock
0 run
1 crash
1 local
1 log
1 mail
1 metrics
1 opt
1 spool
1 tmp
2 backups
182 cache
239 lib
2981 www
-
OK... dos 3.4GB, vc tem 2.9 em /var/www. O que tem lá que possa estar ocupando tanto espaço?
-
A página do Sarg, pra verificar os acessos através do squid.
-
Ahhhhhhh... compacte os relatórios antigos, ou reserve mais espaço pra eles, senão vc vai acabar sem espaço em disco mesmo.
-
editora@bkp-editora:/var/log$ cd /var/www/
editora@bkp-editora:/var/www$ ls -la
total 16
drwxr-xr-x 3 root root 4096 Abr 17 10:22 .
drwxr-xr-x 14 root root 4096 Jun 30 13:22 ..
-rw-r--r-- 1 root root 177 Fev 6 09:18 index.html
drwxr-xr-x 94 root root 4096 Jun 28 00:30 sarg
editora@bkp-editora:/var/www$ du -lhs sarg/
3,0G sarg/
editora@bkp-editora:/var/www$
Mas a pasta sarg está com 3GB só. o.O
-
OK... dos 3.4GB, vc tem 2.9 em /var/www. O que tem lá que possa estar ocupando tanto espaço?
-
Entendi. Realmente, são 226GB na partição, e o /var só está ocupando 3GB.
Repete a verificação na raiz ("/"), mas dessa vez como super-usuário.
-
Muito estranho, ne?
root@bkp-editora:/# du -smx * | sort -n
du: impossível acessar "proc/8917/task/8917/fd/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/8917/task/8917/fdinfo/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/8917/fd/3": Arquivo ou diretório não encontrado
du: impossível acessar "proc/8917/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
-
será que vc tem algum arquivo oculto (iniciado com um ".") na raiz? Execute o comando "ls -la /" pra gente verificar.
-
editora@bkp-editora:~$ ls -la /
total 84
drwxr-xr-x 23 root root 4096 Fev 6 08:39 .
drwxr-xr-x 23 root root 4096 Fev 6 08:39 ..
drwxr-xr-x 2 root root 4096 Fev 6 08:47 bin
drwxr-xr-x 3 root root 4096 Fev 6 08:50 boot
drwxr-xr-x 15 root root 4320 Jun 30 13:38 dev
drwxr-xr-x 98 root root 4096 Jun 30 13:38 etc
drwxr-xr-x 3 root root 4096 Fev 6 08:52 home
lrwxrwxrwx 1 root root 32 Fev 6 08:39 initrd.img -> boot/initrd.img-3.5.0-17-generic
lrwxrwxrwx 1 root root 33 Fev 6 08:39 initrd.img.old -> /boot/initrd.img-3.5.0-17-generic
drwxr-xr-x 18 root root 4096 Mai 18 00:40 lib
drwxr-xr-x 2 root root 4096 Fev 6 09:24 lib64
drwx------ 2 root root 16384 Fev 6 08:37 lost+found
drwxr-xr-x 3 root root 4096 Fev 6 08:38 media
drwxr-xr-x 2 root root 4096 Out 9 2012 mnt
drwxr-xr-x 2 root root 4096 Out 17 2012 opt
dr-xr-xr-x 104 root root 0 Jun 30 13:22 proc
drwx------ 5 root root 4096 Abr 14 11:52 root
drwxr-xr-x 21 root root 720 Jul 2 19:41 run
drwxr-xr-x 2 root root 4096 Mai 18 00:40 sbin
drwxr-xr-x 2 root root 4096 Jun 11 2012 selinux
drwxr-xr-x 4 root root 4096 Mai 17 14:17 srv
dr-xr-xr-x 13 root root 0 Jun 30 13:22 sys
drwxrwxrwt 3 root root 60 Jul 2 19:39 tmp
drwxr-xr-x 10 root root 4096 Fev 6 08:38 usr
drwxr-xr-x 14 root root 4096 Jun 30 13:22 var
lrwxrwxrwx 1 root root 29 Fev 6 08:39 vmlinuz -> boot/vmlinuz-3.5.0-17-generic
lrwxrwxrwx 1 root root 29 Fev 6 08:39 vmlinuz.old -> boot/vmlinuz-3.5.0-17-generic
-
A mensagem do MOTD ta assim, ó:
Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-17-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Wed Jul 2 19:41:19 BRT 2014
System load: 0.0 Processes: 92
Usage of /: 100.0% of 225.33GB Users logged in: 1
Memory usage: 8% IP address for eth0: 192.168.100.200
Swap usage: 0%
=> / is using 100.0% of 225.33GB
Graph this data and manage this system at https://landscape.canonical.com/
156 packages can be updated.
94 updates are security updates.
New release '13.04' available.
Run 'do-release-upgrade' to upgrade to it.
-
Hmmmmmmmm..... acho que já sei o que rolou.
Vc tem essa partição "/srv/Storage1", certo?
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
Quando vc criou/montou, observou se a pasta /srv/Storage1 estava vazia? Pq se não estiver, o conteúdo do sistema de arquivos montado se sobrepõe ao conteúdo da pasta, que fica completamente inacessível.
Uma forma de confirmar isso é desmontar a partição (supondo que não haja processo usando, é só mandar um "sudo umount /srv/Storage1"), e ver se fica alguma coisa lá dentro.
-
Sempre falei que você é o gênio do Forum. Sempre conseguiu desvendar mistérios, hahaha.
Exatamente isso que aconteceu!
root@bkp-editora:/# sudo umount /srv/Storage1
root@bkp-editora:/# cd /srv/Storage1/
root@bkp-editora:/srv/Storage1# ls
BACKUPS INDD BANCO DE ILUSTRAS BANCO DE IMAGEM CONSULTA TEMPORARIA EDITORA ILUSTRAS RECUPERADAS MATERIAL DE APOIO NAT5I Tati TESTE ILUSTRADOR TI
root@bkp-editora:/srv/Storage1# 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
root@bkp-editora:/srv/Storage1#
-
root@bkp-editora:/srv/Storage1# du -lhs /srv/Storage1/
221G /srv/Storage1/
Vou da um rm -rf /srv/Storage1/ e montar novamente..
-
/srv/Storage1/ é um HD externo que fica o backup.
Acredito que quando eu reiniciei a máquina, por algum motivo, ele não montou automáticamente e eu tive que montar manualmente depois. Nisso, nesse meio termo, o rsync entrou em ação e saiu detonando..
-
Sempre falei que você é o gênio do Forum. Sempre conseguiu desvendar mistérios, hahaha.
Genial ou Genioso? ;D
-
/srv/Storage1/ é um HD externo que fica o backup.
Acredito que quando eu reiniciei a máquina, por algum motivo, ele não montou automáticamente e eu tive que montar manualmente depois. Nisso, nesse meio termo, o rsync entrou em ação e saiu detonando..
Se estiver fazendo o backup por script, pode verificar, antes de começar a cópia, se o sistema de arquivos está mesmo montado. Supondo que é um sistema de arquivos ext3, tem que haver uma pasta "lost+found" lá dentro. Se ela não existir, não está montado, daí não faça o backup.
Outra forma seria executar o comando "mount | grep /srv/Storage1 > /dev/null". O resultado vai ser verdadeiro se estiver montado, ou falso caso contrário. Assim pode ser usado num script parecido com isso:
#/bin/bash
...
if mount | grep /srv/Storage1 > /dev/null
then
echo Está montado, manda bala no backup
...
else
echo Não está montado, vou cair fora...
fi
...
-
Massa. Valeu mesmo, cara!
Só achei estranho meus scripts terem sumido de ~/scripts. Eu tinha um bkp.sh e sarg.sh. :(
Sumiu também minhas chaves em ~/.ssh. Que estranho!
-
Aí tem que chamar o Sherlock Holmes... nenhuma chance de ter sobreposto esses arquivos ou deixado de montar mais alguma coisa em /home?
-
Acredito que sobreescreveu. Deixado de montar não. Ficava em /home/usuario/scripts. HD interno.
-
Claro que vc tinha backup deles, não? ;D
Voltando ao assunto do título... normalizou o funcionamento do Squid?
-
Tinha sim!
Normalizou. Ta tranquilo agora!
Tava sem espaço pra receber o resultado do GET que o proxy solicitava. Valeu mesmo, zek! :)
-
Interessante, as versões antigas do squid crashavam "graciosamente" quando ficavam sem espaço pra gerar o log.