Use o dmesg para entender o que está funcionando mal no seu computador

O dmesg ajuda a obter informações, direto do kernel, sobre o que está havendo com o seu sistema.
Com este utilitário, tradicional em sistemas UNIX-like, você irá ter tanto boas, como más notícias.
dmesg show delta
O comando pode ser útil para detectar problemas com drivers e módulos de kernel que não estão funcionando adequadamente. Quando você sabe o que precisa ser “arrumado” no seu sistema, tarefas, como reduzir o tempo de boot podem ser facilitadas.
O dmesg pode dar pistas bem concretas sobre por que sua placa de vídeo ou rede não atende às suas expectativas, por exemplo.
Também uso muito esta ferramenta para acompanhar o suporte do kernel (à medida em que vai sendo atualizado) ao meu hardware.

Como usar o dmesg para obter informações sobre o funcionamento do seu sistema

A ferramenta é muito simples de usar e pode ser acompanhada do comando grep, sempre que você quiser filtrar as informações, para visualizar apenas o que interessa.
Para obter informações sobre erros, vindos da execução do kernel, experimente o seguinte comando:

dmesg | grep -i error

Note que a ferramenta não exige ser executada com privilégios especiais.
Esta característica permite que um usuário comum, sem privilégios administrativos no sistema, possa obter informações sobre seu funcionamento, copiar e colar em uma mensagem para obter ajuda de outros usuários remotamente.
No meu caso, como você pode ver abaixo, temos alguns problemas relacionados ao firmware da minha GPU AMD Topaz XT [Radeon R7 M260/M265].

[    5.120310] amdgpu 0000:04:00.0: Direct firmware load for amdgpu/topaz_mc.bin failed with error -2
[    5.120341] [drm:gmc_v7_0_sw_init [amdgpu]] *ERROR* Failed to load mc firmware!
[    5.120358] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block <gmc_v7_0> failed -2
[    5.120361] amdgpu 0000:04:00.0: Fatal error during GPU init
[    5.120542] amdgpu: probe of 0000:04:00.0 failed with error -2
[ 3460.081234] mce: [Hardware Error]: Machine check events logged
[ 3460.081240] mce: [Hardware Error]: Machine check events logged

Se você usar apenas o comando dmesg, sem parâmetro ou opção alguma, ele irá exibir todas as mensagens do kernel ring buffer.
Por isto, é necessário usar o grep e/ou alguma outra opção, para poder fazer uma investigação mais precisa sobre possíveis problemas que estejam em andamento no seu sistema.
A sua investigação pode continuar, no seu mecanismo de busca favorito, na busca por explicações para as mensagens de erro.

Exemplos de uso do dmesg

Veja alguns exemplos de uso do dmesg que podem ajudar a obter informações sobre o seu hardware ou sobre o sistema operacional.
Use o dmesg para obter a versão do kernel em uso:

dmesg | grep -i "command line"
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 root=UUID=1bde5861-68d5-4f8b-b759-2def64a9e8dc ro quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 root=UUID=1bde5861-68d5-4f8b-b759-2def64a9e8dc ro quiet

Como obter informações sobre a arquitetura (32 ou 64 bits) detectada:

dmesg | grep -i "architedmesg | grep -i "architect"

Note que este comando ajuda, inclusive, a detectar a presença do systemd.

[    3.443553] systemd[1]: Detected architecture x86-64.dmesg | grep -i "architect"

Com o uso da opção ‘–userspace’, o utilitário permite ver as ocorrências do kernel, desde o momento em que o userspace ou modo usuário foi carregado.

dmesg --userspace 
[    3.443437] systemd[1]: systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[    3.443553] systemd[1]: Detected architecture x86-64.
[    3.444484] systemd[1]: Set hostname to <inspiration>.
[    3.677904] systemd[1]: Created slice User and Session Slice.
[    3.677973] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    3.677982] systemd[1]: Reached target Encrypted Volumes.
[    3.678038] systemd[1]: Listening on Journal Audit Socket.
[    3.678046] systemd[1]: Reached target User and Group Name Lookups.
[    3.678070] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[    3.678091] systemd[1]: Listening on Journal Socket (/dev/log).
[    3.678108] systemd[1]: Listening on udev Kernel Socket.
[    3.678133] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    3.678149] systemd[1]: Listening on Syslog Socket.
[    3.678168] systemd[1]: Listening on udev Control Socket.
[    3.678177] systemd[1]: Reached target Remote File Systems.
[    3.678251] systemd[1]: Created slice System Slice.
[    3.678262] systemd[1]: Reached target Slices.
[    3.678333] systemd[1]: Created slice system-getty.slice.
[    3.678476] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    3.678503] systemd[1]: Listening on Journal Socket.
[    3.690010] systemd[1]: Mounting Debug File System...
[    3.690418] systemd[1]: Mounting Huge Pages File System...
[    3.690837] systemd[1]: Mounting POSIX Message Queue File System...
[    3.691373] systemd[1]: Starting Journal Service...
[    3.758083] systemd[1]: Starting Set the console keyboard layout...
[    3.758665] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[    3.759199] systemd[1]: Starting Remount Root and Kernel File Systems...
[    3.759877] systemd[1]: Starting Load Kernel Modules...
[    3.822693] systemd[1]: Mounted Debug File System.
[    3.822724] systemd[1]: Mounted POSIX Message Queue File System.
[    3.822736] systemd[1]: Mounted Huge Pages File System.
[    3.822796] systemd[1]: Started Journal Service.
[    3.913397] systemd-journald[1082]: Received request to flush runtime journal from PID 1
[    6.721371] systemd[1]: apt-daily.timer: Adding 7h 26min 30.367128s random time.
[   17.134471] systemd[1]: apt-daily.timer: Adding 42min 23.553328s random time.
[   21.124814] systemd[1]: apt-daily.timer: Adding 51min 47.360901s random time

Para investigar erros e avisos do sistema, use a opção ‘–level’.
Use ‘–level=err’, para ver apenas mensagens de erro emitidas pelo kernel:

dmesg --level=err

Na sua tela, o seguinte resultado, deve ser exibido em cores predominantemente vermelhas:

[    4.600707] iwlwifi 0000:03:00.0: Unsupported splx structure
[    5.120309] amdgpu 0000:04:00.0: firmware: failed to load amdgpu/topaz_mc.bin (-2)
[    5.120311] cik_mc: Failed to load firmware "amdgpu/topaz_mc.bin"
[    5.120341] [drm:gmc_v7_0_sw_init [amdgpu]] *ERROR* Failed to load mc firmware!
[    5.120358] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block <gmc_v7_0> failed -2
[    5.120360] amdgpu 0000:04:00.0: amdgpu_init failed
[    5.120361] amdgpu 0000:04:00.0: Fatal error during GPU init
[    5.120363] [TTM] Memory type 2 has not been initialized

Veja uma imagem do meu terminal, após executar o comando acima:
dmesg kernel errors
Para ver apenas as mensagens de aviso (warnings), use o comando assim:

dmesg --level=warn

Neste caso, o resultado pode ser bem mais extenso.
Você pode combinar os 2 parâmetros, separando-os por vírgulas:

dmesg --level=err,warn

Mensagens de nível crítico podem ser exibidas com o parâmetro ‘crit’:

dmesg --human --level=crit
[out 1 09:56] CPU0: Core temperature above threshold, cpu clock throttled (total events = 1)
[  +0,000001] CPU2: Core temperature above threshold, cpu clock throttled (total events = 1)
[  +0,000001] CPU3: Package temperature above threshold, cpu clock throttled (total events = 1)
[  +0,000002] CPU1: Package temperature above threshold, cpu clock throttled (total events = 1)
[  +0,000002] CPU2: Package temperature above threshold, cpu clock throttled (total events = 1)
[  +0,000006] CPU0: Package temperature above threshold, cpu clock throttled (total events = 1)

Veja todos os níveis de mensagens que você pode usar com a opção ‘–level’:

Parâmetro Descrição
emerg emergengy ou emergência — sistema está inutilizável
alert ação deve ser tomada imediatamente
crit condições críticas
err condições de erro
warn condições de aviso
notice condição normal, mas significativa
info informativo
debug mensagens de nível de depuração

No Linux, estas 2 formas de uso são válidas:
dmesg --level=err
ou
dmesg --level err
Use o que achar melhor.
Você pode restringir a saída a recursos específicos do sistema, com a opção ‘–facility’.
Para obter resultados unicamente sobre os serviços ou daemons em execução no sistema, use-o da seguinte forma:

dmesg --facility daemon 
[    3.443437] systemd[1]: systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[    3.443553] systemd[1]: Detected architecture x86-64.
[    3.444484] systemd[1]: Set hostname to <inspiration>.
[    3.677904] systemd[1]: Created slice User and Session Slice.
[    3.677973] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    3.677982] systemd[1]: Reached target Encrypted Volumes.

...

[    3.822693] systemd[1]: Mounted Debug File System.
[    3.822724] systemd[1]: Mounted POSIX Message Queue File System.
[    3.822736] systemd[1]: Mounted Huge Pages File System.
[    3.822796] systemd[1]: Started Journal Service.
[    6.721371] systemd[1]: apt-daily.timer: Adding 7h 26min 30.367128s random time.
[   17.134471] systemd[1]: apt-daily.timer: Adding 42min 23.553328s random time.
[   21.124814] systemd[1]: apt-daily.timer: Adding 51min 47.360901s random time.

Se você está com o computador ligado há muito tempo, o dmesg pode ter uma quantidade excessiva de informações para exibir. Muitas delas, podem nem fazer mais sentido. Para limpar o buffer de mensagens do dmesg, use a opção ‘–clear’ (c/privilégios administrativos):

dmesg --clear

Como detalhar as atualizações de pacotes com apt, apt-get e aptitude

Sempre surge alguma curiosidade específica, sobre algum pacote de software, em particular, que está para ser atualizado no meu sistema.
Esta dica funciona no Ubuntu e no Debian e pode ser aplicada com os comandos apt, apt-get ou o aptitude.
Quem usa o Debian Testing ou o Ubuntu Alpha/Beta, pode ter que atualizar diariamente o seu sistema.
Este “incômodo” é o preço que se paga para usar software atualizado e (razoavelmente) seguro.
Claro que o processo de atualização diária do sistema sempre pode ser incluído no cron, caso seja um incômodo.
Eu gosto, contudo, de acompanhar as mudanças no software instalado em meu notebook pessoal.
Portanto, diariamente, tenho o costume de rodar o comando apt para verificar e fazer as atualizações necessárias.

Este texto é para aqueles casos em que você se pergunta “que diabos estão atualizando neste pacote, aí?”

Como detalhar atualizações de um pacote com o apt-get, apt ou aptitude

Tanto faz usar um como o outro. O resultado é o mesmo.
Com a opção ‘changelog’, é possível baixar e mostrar os relatório de atualizações dos pacotes. Veja um exemplo, envolvendo o pacote do wget:

apt-get changelog wget

O resultado exibe o log de atualizações e correções de bugs em ordem de data, a partir da mais recente:

wget (1.18-2) unstable; urgency=medium

  * added OpenSSl 1.1.0 patch from upstream git. closes: #828599

 -- Noël Köthe <noel@debian.org>  Sat, 02 Jul 2016 16:45:14 +0200

wget (1.18-1) unstable; urgency=medium

  * new upstream release from 2016-06-10
    - fixed CVE-2016-4971 closes: #827003
    - fixed segmentation fault when terminal width is small. closes: #823891
  * debian/control: updated Standards-Version, no changes needed
  * debian/changelog fixed spelling errors

 -- Noël Köthe <noel@debian.org>  Sat, 11 Jun 2016 20:30:44 +0200

wget (1.17.1-2) unstable; urgency=low

  * applied patch from Margarita Manterola. Thanks a lot:
    - Add udeb support, taken from the work done by Colin Watson for Ubuntu
      in 1.10.2-2ubuntu2 and forward.
    - Added dependency on libssl-dev for the udeb, as gnutls does not provide
      a udeb package.

...

Só pela curiosidade, é possível ver, na listagem acima, que existe trabalho da hacker argentina Margarita Manterola, na correção de bugs no wget.
Se você prefere usar o apt para realizar o trabalho, tudo funciona igual. Veja:

apt changelog systemd

Esta é uma forma de acompanhar a evolução de seus aplicativos favoritos.
Para os que preferem usar o aptitude, o procedimento é idêntico:

aptitude changelog wget

wget changelog

Como monitorar vários arquivos de log com o MultiTail

O aplicativo MultiTail permite ver vários arquivos de log em seu sistema, com a criação de divisórias (uma para cada log) dentro da janela de um único console, com o uso da biblioteca ncurses.
Pode-se dizer que seja uma versão melhorada do utilitário Tail.
Desenvolvido por Folkert Vanheusden, o aplicativo é multiplataforma, com suporte a UNIX, GNU/Linux, Mac OS X e Windows (através do Cygwin).
Multitail logo and woman
Entre seus recursos, citam-se:

  • Monitoramento de wildcards — caso um arquivo, que preencha requisitos preestabelecidos, tenha data ou hora de modificação mais atual, o programa prioriza seu monitoramento.
  • Junção de duas ou mais fontes de entrada de dados.
  • Por meio de expressões regulares, exibe resultados em cores na tela — o que ajuda a distinguir informações importantes.
  • Filtro de linhas.
  • Menus interativos para editar expressões regulares e para remover ou adicionar janelas.
  • Permite usar a saída produzida por outros aplicativos ou shell scripts.
  • Imita as funcionalidades de ferramentas como o watch, quando analisa a saída de algum software externo.

Nos tópicos que seguem, pretendo abordar vários aspectos do MultiTail, o que inclui técnicas de instalação, o uso básico e alguns exemplos comuns em que ele pode ser aplicado para monitorar o seu sistema.

Sinta-se à vontade para ir direto ao ponto que te interessa ou guardar o texto no menu favoritos, para usar como referência em outro momento.

Ao iniciar o Multitail (sem qualquer parâmetro), o aplicativo limpa a tela e exibe algumas teclas de atalho que você pode usar, ao lado de uma curta explicação sobre o que cada uma delas faz.
Tecle ‘F1’ ou ‘Ctrl + h’ para obter mais ajuda, dentro do aplicativo. Para finalizá-lo, tecle ‘q’, ‘x’ ou ‘Ctrl +C’.

Como instalar o MultiTail

Neste artigo, abordamos o uso do MultiTail em um sistema GNU/Linux Ubuntu 14.04 LTS. Como em qualquer outro sistema baseado no Debian, o aplicativo pode ser instalado via apt-get:

sudo apt-get install multitail

Se você usa outro sistema operacional, use o utilitário de instalação que se aplica a sua situação.

Como baixar e compilar a última versão do MultiTail

Há várias razões para querer compilar o código fonte de um aplicativo — ter em mãos uma versão mais nova e mais eficiente, são duas delas.
Se você tiver interesse em saber mais sobre como compilar seus programas no Linux, leia o artigo Como compilar código fonte.


No Ubuntu 14.04, o MultiTail está disponível na versão 6.0:

multitail -V
 --*- multitail 6.0 (C) 2003-2013 by folkert@vanheusden.com -*--

Thank you for using MultiTail.
...

Se você está satisfeito com a versão que tem no seu sistema, pule esta seção.
Se preferir tentar baixar e compilar o código fonte, pode se surpreender com a facilidade do processo, descrito a seguir.
Tenha o cuidado de remover a versão antiga, caso a tenha instalado, antes de trazer a nova — isto evita confusão.
A partir do site oficial é possível baixar uma versão mais nova (link ao final do texto):

wget http://www.vanheusden.com/multitail/multitail-6.4.1.tgz

Depois de baixar, descompacte o código, entre no diretório de instalação e compile:

tar xvvzf multitail-6.4.1.tgz
cd multitail-6.4.1/
sudo apt-get install libncursesw5-dev
sudo make install

Feito isto, o novo aplicativo já estará instalado e pronto para ser executado:

multitail

Como usar o MultiTail

multitail-apache-logs-access-error-Screenshot
O aplicativo tem um grande número de opções — todas documentadas no manual UNIX/Linux ou no sistema de ajuda do aplicativo — tecle ‘Ctrl + h’ para chegar lá, conforme destacado na imagem abaixo:
Captura de tela da ajuda do multitail
Você pode percorrer a tela de ajuda com as teclas de direcionamento e não precisa estar com o inglês “muito em dia” para entender a maior parte do texto.
Ao iniciar o MultiTail, você terá resultados mais imediatos, se já oferecer os arquivos de log que deseja monitorar.
Na figura acima, usei os arquivos de log do Apache: access.log e error.log:

multitail /var/log/apache2/access.log -I /var/log/apache2/error.log

Neste caso, se você tiver o Apache instalado no seu sistema, ao acessar o endereço http://localhost, perceberá alteração na tela de monitoramento.
Veja algumas opções comuns de uso do MultiTail:

  • --closeidle N — permite especificar um período de inatividade de N segundos, após o qual o aplicativo fecha a janela referente ao arquivo de log ocioso.
    É útil para quando se está monitorando um grande número de arquivos, mas só quer que sejam exibidos resultados daqueles que estão verdadeiramente ativos.
    Seja cuidadoso com o uso desta opção — a janela não vai se reabrir, caso o arquivo seja atualizado depois de ter sido fechada.
  • -i file — permite declarar os nomes dos arquivos de log que se deseja acompanhar.
    Normalmente, você só precisa listar os arquivos na linha de comando, um após o outro.
    Preceder o nome de um arquivo com ‘-i’ permite monitorar aqueles cujos nomes começam com um traço (-) — caso contrário, o nome do arquivo será entendido como uma opção de linha de comando do MultiTail, o que pode acabar retornando um erro.
  • --mark-interval N — Permite que se especifique um intervalo de tempo, em N segundos, de inatividade que faz com que uma linha marcadora seja exibida na janela de resultados do MultiTail.
    Por exemplo, caso não haja atividade no log do servidor web Apache, em N segundos, o programa exibe uma linha ---auth.log DATE TIME---, em que DATE TIME é a data e hora.
    Esta opção é especialmente útil para identificar os arquivos de log que não estão tendo muita atividade.
  • --no-repeat — evita a repetição ou redundância de mensagens ao informar apenas quantas vezes a última mensagem foi repetida: “Last message repeated N times”.

Veja o exemplo abaixo:

multitail --mark-interval 10 --no-repeat /var/log/kern.log /var/log/mysql.log

Multitail monitor kernel and mysql
Como você já pôde perceber, o MultiTail divide a tela em partes iguais para cada arquivo de log. Você pode ampliar a janela do console se quiser… mas o fato é que as 2 últimas linhas já costumam ser suficientes para acompanhar e detectar se algo anormal está acontecendo.

Use o MultiTail para monitorar as saídas dos comandos

Há casos em que o conteúdo do que está sendo escrito em um arquivo de log não é tão importante — o administrador deseja apenas saber se ele está sendo atualizado, como consequência de algum aplicativo estar funcionando no sistema.
Um dos exemplos disto é log de acessos do Apache — cujo uso pode ser bastante intenso em alguns servidores.
O servidor web pode gerar milhares de mensagens de log em questão de minutos — cada qual contém detalhes que raramente são muito úteis.
Em casos como este, o que os administradores de sistemas realmente querem é verificar se o arquivo de log está sendo alimentado — ou, em outras palavras, que o servidor está no ar e recebendo acessos.
Manualmente, você pode acompanhar o crescimento do arquivo de log de acessos do servidor web com o comando ‘ls -l’:

ls -l /var/log/apache2/access.log-rw-r----- 1 root adm 21444 Ago  1 20:29 /var/log/apache2/access.log

Você acompanha os acessos através da repetição deste comando. Chato, não?
Para usar o MultiTail para acompanhar apenas as saídas de um programa, é necessário incluir algumas opções na linha de comando. Veja:

multitail -Rc 2 -l "ls -l /var/log/apache2/access.log"

Multi tail and apache


Este é um caso em que o MultiTail mimetiza outro programa: o watch.
O aplicativo watch está presente, por padrão, na maioria das distribuições Linux.
Ele também pode ser usado para resolver o problema acima, com esta linha de comando:

watch "ls -l /var/log/apache2/access.log"

Faça a experiência.

Exemplos de uso do MultiTail

Foi dito, antes, que o MultiTail “divide a janela do console em partes iguais”. Sendo um comportamento padrão do aplicativo, há opções para dividir a tela de outras maneiras mais cômodas para você acompanhar o andamento do sistema.
O exemplo abaixo mostra a divisão da tela em 3 sessões, em que o primeiro arquivo de log monitorado ocupa um espaço maior. Veja:

multitail -s 2 /var/log/apache2/error.log /var/log/apache2/access.log /var/log/gpu-manager.log

multitail -s 2 /var/log/apache2/error.log /var/log/apache2/access.log /var/log/gpu-manager.log
No segundo exemplo, mostro como integrar os logs de 2 aplicativos em apenas uma janela — cada log, contudo, terá sua própria cor.
Os logs de acessos e erros de um servidor podem ser um pouco “maçantes” e conter muita informação redundante — motivo pelo qual um administrador pode optar por deixá-los juntos em uma única janela.
A diferença de cores, permite acompanhar com clareza o andamento do log de cada um:

multitail -ci green /var/log/apache2/access.log -ci red -I /var/log/apache2/error.log

multitail -ci green /var/log/apache2/access.log -ci red -I /var/log/apache2/error.log

Referências

Site oficial do MultiTail: http://www.vanheusden.com/multitail/
Página do desenvolvedor no GitHub: https://github.com/flok99/multitail
Artigo no Wikipedia: https://en.wikipedia.org/wiki/MultiTail
Documentação do MultiTail: http://linux.die.net/man/1/multitail

Como monitorar o sistema com o tail

Arquivos de log existem para criar relatório que mostram como um sistema ou um aplicativo está se comportando.
Em sistemas UNIX ou GNU/Linux, arquivos de log são compostos de informações em texto puro e são continuamente acrescidos de novas informações.
Estas informações são fornecidas ou pelos processos em execução na máquina ou por daemons, que produzem informações de log.
Sistemas UNIX ou UNIX-like tem um daemon responsável por criar e manter o log do sistema — usualmente chamado syslogd ou, simplesmente, syslog (que manipula relatórios vindos de diferentes aplicações e servidores).
O Linux tem, ainda, um aplicativo chamado klogd — um daemon para monitorar especificamente as mensagens do kernel.

Como usar o tail

O tail é um dos comandos clássicos usados para monitorar alterações em arquivos no sistema, o que inclui arquivos de log.
Sua função é mostrar as últimas 10 linhas (um padrão que pode ser mudado) de um arquivo.
Sua sintaxe é tail nome_do_arquivo. A execução é finalizada logo após a exibição das 10 últimas linhas do arquivo.
Executado desta forma, o tail não é tão útil para realizar monitoramento algum.
Administradores de sistema – quando usam o tail –, o invocam com a opção -f — que mantém a exibição, continuamente, das últimas linhas do arquivo especificado na linha de comando.
O tail é útil para monitorar múltiplos arquivos de log simultaneamente.
Processos específicos do servidor, que você queira acompanhar, normalmente escrevem seus próprios arquivos de log, enquanto o syslog envia diferentes tipos de mensagens a diferentes tipos de arquivos de log — o que depende de como ele esteja configurado em /etc/
syslog.conf
.
Nos servidores Ubuntu, ele pode ser usado para acompanhar tanto o

  • /var/log/auth.log — onde são registradas as requisições para se autenticar no sistema,
  • quanto o

  • /var/log/kern.log — onde são registradas as mensagens do kernel.

Em servidores web Apache é interessante monitorar ambos os arquivos padrão de log do Apache — /var/log/apache2/access.log e /var/log/apache2/error.log.

tail montoramento do apache
Clique para ver detalhes

A figura acima, mostra duas telas do terminal abertas, cada qual monitora um arquivo de log do Apache.
Embora esta solução consuma uma boa parte da área da sua tela, isso não é problema para clientes com interfaces gráficas Linux, que podem jogar a atividade toda para um desktop virtual.

Exemplos de uso do tail

Se você está monitorando o log de um aplicativo que irá mostrar uma mensagem ao final, pode pedir para o tail só mostrar a mensagem indicadora de que a tarefa terminou. No exemplo, a seguir, o comando grep vai mostrar a frase Finished: SUCCESS”, mas você deve adequar esta linha de comando ao contexto que você tem aí:

tail -f meuarquivo.log | grep -qx "Finished: SUCCESS"

em que

  • -q pede para o grep para ficar em silêncio (quiet), até encontrar a string desejada
  • -x estabelece a condição de que a string buscada ocupe toda a linha

Se você prefere que o tail retorne um número diferente de 10 linhas, use a opção -n:

tail arquivo.txt -n 15

Para monitorar apenas uma determinada ocorrência use um pipe para o comando grep.
No exemplo abaixo, o tail monitorará o arquivo access.log.
Além disto, ele enviará as dez últimas linhas do arquivo e todas as novas que forem adicionadas ao utilitário grep.
O grep lê as informações que o tail envia e exibe apenas as que contiverem 192.168.1.5.

tail -f access.log | grep 192.168.1.5

Este exemplo demonstra como selecionar em tempo real o que exatamente você deseja monitorar dentro de um arquivo de log.

Alternativas ao tail

O tail é uma ferramenta clássica de monitoramento que, por padrão, inquire o arquivo a cada segundo — este comportamento pode ter um impacto significativo em equipamentos já sobrecarregados de trabalho.
Alguns administradores sugerem o uso de less, como alternativa rudimentar (mas eficaz) ao tail.
Monitoramento simultâneo de vários arquivos, pode ser feito com o multitail e com ganho de eficiência. Mas isto será alvo de um novo artigo.


Referẽncias:
http://unix.stackexchange.com/questions/45941/tail-f-until-text-is-seen.
http://www.computerhope.com/unix/utail.htm.

Como criar scripts a partir do histórico de comandos do MySQL

As queries ou consultas feitas no cliente interativo MySQL, que funcionam bem, podem ser facilmente convertidas em scripts para automatizar suas tarefas ou adiantar o seu trabalho como desenvolvedor — seja qual for a sua linguagem de programação.
Logo MySQL sobre um fundo com um lago e um barco
A solução relatada neste artigo permite reusar as queries, de uma sessão anterior do MySQL, que estão funcionando para você, em um script.

Use um arquivo tee ou o histórico do MySQL

Uma das formas de reusar as queries MySQL, dentro de um script, é buscá-las a partir de um arquivo tee.
No artigo, Como guardar o histórico dos comandos no MySQL em um arquivo externo, eu explico o procedimento em detalhes.
Outra forma, é buscar as queries no arquivo de histórico padrão do MySQL, importar o texto e ir retirando tudo o que não serve ao seu script.
Neste caso, comece por digitar suas queries no cliente MySQL, normalmente — se certificando de que estejam funcionando sintaticamente e entregando os resultados desejados.
Em seguida, saia do MySQL, com o comando quit e liste o arquivo do histórico da sua sessão, da linha de comando:

cat .mysql_history

No Linux, o arquivo do histórico costuma ficar armazenado no seu diretório home.
Experimente combinar o comando cat com o comando grep, para obter resultados mais precisos em relação ao que te interessa:

cat .mysql_history grep -e select

Exemplo de execução do comando cat com o comando grep
Clique, para ver detalhes.

O arquivo do histórico, bem como aquele criado pelo comando tee, pode ser aberto no seu editor de scripts favorito, de onde você pode extrair as queries que deseja e editá-las como bem entender.
captura de tela komodo editor