Obtenha mais informações sobre a falha

Quando emito o comando lastno meu terminal, vejo as seguintes entradas, ou seja, "falha":

eu quis dizer o comando last "show list of last logon users".

root@lab18:~# last
tito     pts/3        x.x.x.x   Tue Nov 13 16:22   still logged in
tito     pts/3        x.x.x.x   Tue Nov 13 09:13 - 16:22  (07:09)
reboot   system boot  3.2.0-32-generic Mon Nov 12 23:58 - 16:22  (16:24)
tito     pts/1        192.168.26.5     Mon Nov 12 23:56 - crash  (00:01)
tito     pts/4        192.168.26.5     Mon Nov 12 22:46 - crash  (01:12)


uname -a
Linux HomeServer 3.2.0-32-generic-pae #51-Ubuntu SMP Wed Sep 26 21:54:23 UTC 2012 i686 i686 i386 GNU/Linux
last reboot
reboot   system boot  3.2.0-32-generic Mon Nov 12 23:58 - 16:29  (16:31)
wtmp begins Thu Nov  1 10:17:16 2012

Eu encontrei algumas informações sobre a falha no syslog e no kernel.log. No entanto, fiquei curioso para saber se várias distribuições Linux (ubuntu) estão escrevendo outros arquivos além do syslog ou kernel.log, onde informações específicas sobre a falha podem ser decodificadas. E o que eu quero dizer é, por exemplo, que muitos fornecedores de redes, por exemplo, Cisco, HP, Juniper, Enterasys possuem syslog, current.log, SNMP informa / intercepta mensagens que são salvas em algum local no sistema de arquivos ou remotamente. caso isso ocorra, no entanto, eles também criaram arquivos especificamente projetados, como systemDumps, em que um backtrace da pilha de chamadas pode ser encontrado e analisado caso ocorra uma falha e, ocasionalmente, isso pode ajudar a depurar o problema. Portanto, a questão é se o Ubuntu também possui esse tipo de lugar onde as informações estão sendo armazenadas sobre o acidente.

Saudações,

Tito

command-line logs

— Tito
fonte

Não está realmente claro de onde vêm essas linhas, o que travou etc. Que comando 'último' você está executando? Até onde eu sei, o lastcomando que você normalmente executaria é este: show listing of last logged in users(da página de manual).

Você está verificando last reboot? Nesse caso, e isso significa que seu sistema travou antes de uma reinicialização, você pode começar verificando os logs do sistema:

less /var/log/syslog

ou, se isso for muito novo

less /var/log/syslog.1

Se você precisar de uma entrada mais antiga, é provável que eles sejam compactados com gzip, use zo

zcat /var/log/syslog.2.gz

Em algumas versões (instalação do servidor), você pode precisar de permissões especiais para ler esses arquivos; portanto, se você receber uma

/var/log/syslog: Permission denied

erro, você precisa acrescentar seus comandos com sudo

sudo less /var/log/syslog

— Nanne
fonte

@ Mik: Eu acredito que você está incorreto em sua edição: no meu sistema, temos isso -rw-r----- 1 syslog adm 16K Nov 13 11:30 sysloge meu usuário precisa usar o sudo para lê-lo.

— Nanne

No meu Ubuntu 12.04 LTS, o sudo não é necessário e, normalmente, não é necessário, pelo menos para os sistemas de desktop.

Não houve menção de qual versão e como existem versões que exigem isso (e até onde eu sei não há problema em usar um comando 'sudo' extra), parece-me que deixar o sudo no lugar é A melhor opção? (btw, eu não estava pensando em uma edição-guerra, poderíamos encontrar no meio e apenas adicionar esta conversa na resposta?)

— Nanne

Sim, você pode colocar uma nota sobre isso na resposta.

Olá, desculpe pelo mal-entendido. Eu editei a pergunta e a tornei mais detalhada.

— Tito