A algum tempo eu estou tendo problemas com o meu syslog. O syslog é o sistema que armazena mensagens sobre eventos nos sistemas UNIX-Like, ou seja, tudo o que acontece no sistema é armazenado em arquivos chamados arquivos de log ou de registro.
Aparentemente quando eu fecho a tampa do meu netbook o sistema as vezes começa a gerar linhas de log no arquivo /var/log/syslog até encher a minha partição /var de 2GB. Quem é mais meticuloso vai perceber que o problema não é o syslog mas sim algo que inicia os eventos que geram logs. Mas de qualquer forma isto proporciona um ataque de negação de serviço à minha própria máquina, já que quando a partição /var fica cheia o sistema não funciona mais corretamente. Este problema já ocorreu umas três vezes desde que eu comprei o meu netbook, mas hoje eu tive este problema durante uma aula e decidi tentar resolve-lo (demorei muito tempo para isto… procrastinação… rsrsrs).
Para uma solução provisória fui atrás do logrotate e descobri que o mesmo não está controlando o tamanho dos arquivos de log no Slackware 13.1 de 64 bits. Então, eu acrescentei a opção size=10M no arquivo /etc/logrotate.conf. Isto limita o arquivo de log para 10MB. Também copiei o arquivo /etc/cron.daily/logrotate para /etc/cron.hourly/logrotate (só para ver esta está funcionando a curto prazo), com isto o meu sistema vai executar o logrotate de hora em hora e eu espero que isto resolva o meu problema, pelo menos temporariamente.
Futuramente (provavelmente até dar problema novamente) eu pretendo procurar mais a fundo o que esta gerando as mensagens de log, mas eu acho que é a hibernação do sistema, pois isto ocorre quando eu acabo de retirar o cabo de energia e fecho a tampa do netbook.
Vamos ver o que vai dar!!!
😀
Segue os arquivos que eu editei:
Arquivo de configuração do logrotate – /etc/logrotate.conf
# /etc/logrotate.conf
#
# logrotate is designed to ease administration of systems that generate large
# numbers of log files. It allows automatic rotation, compression, removal, and
# mailing of log files. Each log file may be handled daily, weekly, monthly, or
# when it grows too large.
#
# logrotate is normally run daily from root’s crontab.
#
# For more details, see “man logrotate”.
# rotate log files weekly:
weekly
# keep 4 weeks worth of backlogs:
rotate 4
# Luiz Arthur
size=10M
# create new (empty) log files after rotating old ones:
create
# uncomment if you want to use the date as a suffix of the rotated file
#dateext
# uncomment this if you want your log files compressed:
#compress
# some packages install log rotation information in this directory:
include /etc/logrotate.d
# Rotate /var/log/wtmp:
/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}
# Rotate /var/log/btmp:
/var/log/btmp {
monthly
create 0600 root root
rotate 1
}
O Arquivo a seguir eu coloquei em /etc/cron.hourly/logrotate:
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
[ $? != 0 ] && /usr/bin/logger -t logrotate “ALERT – exited abnormally.”
Atualizando este Post!
O meu problema com a partição de log continua… a solução apresenta neste Post funciona! Porém, não neste meu caso.
Eu terei que pesquisar mais a fundo o que esta causando o problema com o log no ASUS EEEPC 1201pn. Consegui apurar melhor e parece que o problema ocorre somente quando a bateria esta totalmente completa e eu fecho a tampa do netbook para ele suspender. Nesta segunda-feira eu consegui ver uma mensagem de log, correndo na tela, dizendo que havia um problema com a partição sda14 (que não é a /var)…
Então continua o mistério!
Acho que eu resolvi o mistério…
O problema aparentemente era uma inconsistência no sistema de arquivos e quando eu fechava a tampa do netbook, em um determinado momento ele por algum sinistro deixava o meu arquivo syslog com o tamanho da partição. Por isto o passo que eu executei com logrotate não dava conta do problema, pois isto era automático (só no fechar da tampa, portanto ocorria em menos de uma hora).
Bem, para resolver executei:
# fsck.reiserfs /dev/sda14
# fsck.reiserfs /dev/sda14 –rebuild-tree
Vamos ver se o problema não ocorre mais…