Como o Google Earth pode induzir a reinstalação de uma distro Linux

O problema principal é a falta de espaço no HD, que pode bloquear login de usuário comum. O presente artigo descreve o problema em detalhes.

[ Hits: 15.253 ]

Por: j g meinhardt em 21/02/2010


Moral da estória



Moral da estória:

Nem sempre aquele ultimo aplicativo que você acabou de instalar e que além de tudo estava rodando quando ocorreu o problema de travamento grave, necessariamente será o causador do problema. Calma, não desinstale direto sem investigar primeiro.

Se não procurarmos investigar as causas reais de um travamento, podemos chegar a conclusão errônea de que aquele aplicativo foi o causador do mesmo, neste caso o Google Earth. Na verdade, não só o Google Earth como qualquer outro aplicativo com uso intenso de cache teria causado o mesmo problema.

Por esta razão apresentei o título deste artigo da forma como foi feita, "Como o Google Earth pode induzir a reinstalação de uma distro Linux - Falta de espaço no HD pode bloquear login de usuário comum".

Além desta conclusão, foi possível apreender também outros pontos importantes, ainda que não diretamente ligados ao problema, como a seguir:

1. Quando fizer algum backup, principalmente se for de dados importantes ou daquela distro que você usa com frequência, tente pelo menos uma vez, fazer a recuperação para testar se tudo funciona bem.

2. Faça backups regularmente e com boa frequência, mesmo em sistemas confiáveis como o Linux. Não de chance ao azar.

3. Antes de instalar algum aplicativo que sabidamente usa algum tipo de arquivo de cache volumoso para permitir acesso offline a dados normalmente disponíveis na Internet, verifique o espaço disponível para isto, seja na partição /home caso esteja separada do raiz (/) ou diretamente no raiz, quando o /home estiver junto.

4. Tenha a mão ou instalado em seu HD outra distro em perfeito funcionamento ou pelo menos uma distro em mídia-Live bem atualizada para poder sair de situações de aperto como esta, editar arquivos de configuração, examinar partições etc.

Este ponto terá muito mais importância se você for apenas um usuário não especialista que não lembra ou não sabe onde ficam localizados os arquivos de configuração que precisam ser examinados e/ou reeditados, arquivos executáveis de aplicativos etc. Com uma segunda distro, mesmo minimalista, você terá acesso por interface gráfica a todas as partições onde está aquela sua distro que travou e teima em não reiniciar.

5. Procure descobrir as razões quando ocorrer algum problema, pois só assim a gente apreende algo mais além do normal disponíveis apenas pelos tutoriais ou manuais.

Página anterior    

Páginas do artigo
   1. Introdução
   2. Afinal o que e porque aconteceu?
   3. Moral da estória
Outros artigos deste autor

Porque migrar para o Linux - No meu caso também, preguiça

Kernel 3.0-0 já disponível no aptosid e operando de forma estável

Experiencias de um viajante - binômio sidux/Ceni novamente destaque

Linux também pode ser bom para a terceira idade - "Ginástica" mental pode ajudar a prevenir Alzheimer

Instalando sidux em pendrive para usar como "Canivete Suíço"

Leitura recomendada

Instalando o CMS Drupal 4.7

Slax - O seu Slackware de bolso

Instalando o VirtualBox no Ubuntu 10.04

Instalação de template para monitoramento de servidor Squid e servidor LDAP no CACTI (Debian)

Zorin OS - interessante distro lançada no ano novo - primeiras impressões

  
Comentários
[1] Comentário enviado por stack_of em 22/02/2010 - 12:03h

Travamentos do sistema ocorrem no Linux, com uma frequencia razoavel.
Acho que o principal culpado é mesmo o X-org, e perda de trabalho às vezes é inevitavel.

O X-org tem experimentado uma evolucao mas ainda esta bem longe de ser o ideal.

No seu caso espaço físico no HD foi a causa do problema, e graças ao seu espírito investigativo o determinante do problema foi encontrado, evitando a culpar inocentes (o SO ou o time do Google Earth).

Aconselho instalacao do /root, /home /boot em partições separadas, pois ajuda a prevenir problemas desse tipo. Mas bem que as distros deveriam implementar um sistema de quotas de disco ou de aviso de falta crítica de espaço por padrão.

O máximo de cuidado com backups em ambiente de produção é outro ponto que você enfatizou com propriedade; afinal falhas ocorrem em qualquer sistema operacional e algumas são imprevisíveis.

[2] Comentário enviado por eldermarco em 22/02/2010 - 13:28h

É verdade, isso acontece comigo também na Universidade, onde tem o Debian instalado. Se eu ultrapassar a minha quota de disco (120MB) o sistema já não me permite mais um login em modo gráfico e começa a mostrar uns erros e volta para a tela de login. Eu não cheguei a ver, mas acho que o arquivo ~/.xession-errors deve mostrar algo com respeito a isso, da interface gráfica não ter sido carregada.

De qualquer maneira, no meu caso ainda é possível logar em modo texto, apagar algumas coisas desnecessárias e fazer login em modo gráfico sem problemas depois.

Mas obrigado pelo alerta, vou tratar já de fazer o backup das minhas músicas aqui ou terei um treco se souber que perdi elas =)


[3] Comentário enviado por doradu em 22/02/2010 - 14:34h

tenho problemas com as fontes (no SliTaz), só isso


[4] Comentário enviado por irado em 23/02/2010 - 10:37h

o usuário stack_of (comentário nr. 1) ou é completamente equivocado ou maldoso mesmo. Ou nao usa Linux ;) hehehehhe...

apesar disso, fez duas assertivas corretissimas:

1 - partições distintas - pelo menos para /home (no caso de sistemas domésticos) ou /var e/ou /usr (sistemas corporativos).

2 - backups frequentes.

desde que me conheço por gente eu ouço recomendações para backup. Mas ninguém ouve/executa. Aqui eu faço 1x por semana, salvando tudo em DVDs (usando o k3b, eu gero um iso). DVDs hoje em dia (se comprados em lotes de 50 unidades) chegam a custar RS$.0,80 cada e salvam 4.7G de dados. Se compactados, êsses dados podem ser MUITOS. Pode-se (eu faço assim) tar.gz os dados a serem salvos e, se excecendo 4.7G fraciona-los em 2 DVDs. Pode-se também tirar-se um "espelho" único, mensal e depois incremental, 1x por semana (daí cabe em CDrom mesmo, normalmente) - enfim, IMMV.

nota: SEMPRE se tem 5% disponiveis para o usuário root. É do sistema, para permitir sua recuperação. Então, quando tudo falha, o root ainda tem acesso.


[5] Comentário enviado por meinhardt_jgbr em 23/02/2010 - 10:48h

Nas primeiras vezes que instalei o Mandrake, cheguei a usar uma pequena partição separada também para o /boot porém hoje em dia faço as instalações apenas com três partições, uma para o swap, outra para o sistema ou raiz (/) e outra para os dados e configurações (/home).

Cheguei mesmo a pensar a voltar a deixar o /boot em partição separada, principalmente pensando em várias distros instaladas ao mesmo tempo e com isto facilitar a edição dos arquivos de configuração quando instalo novas distros. Com a chegada do GRUB2 em muitas distros em substituição ao Grub Legacy, talvez isto venha a facilitar.

[6] Comentário enviado por Marcus-RJ em 23/02/2010 - 13:57h

Concordo com o usuario @stack_of , realmente o Xorg e ate mesmo outros componentes como KDE/GNOME tem dado trabalho no gnu-linux, e acontece do sistema "congelar". Muitas vezes devido a blobs da nvidia e afins.
Nao foi o caso deste artigo (meio ao estilo "Eduardo e Monica/Faroeste Cabloco", Legiao Urbana), no entanto.

Abs!


Contribuir com comentário