As informações ou relatórios coletados são enviados para um sistema de rastreamento de bugs.
Se algum processo no sistema morrer devido a um sinal que é comumente chamado de 'falha' (violação de segmentação, erro de barramento, exceção de ponto flutuante etc.), ou por exemplo, um aplicativo Python empacotado gera uma exceção não capturada, o back-end da apport é invocado automaticamente.
Ele produz um relatório de falha inicial em um arquivo em / var / crash / (o nome do arquivo é composto pelo nome do executável com falha e pelo ID do usuário). Se o processo travado pertencer ao usuário que está conectado no momento ou pertencer a um processo do sistema e o usuário for um administrador, o apport informará o usuário sobre o travamento e se oferecerá para relatar o problema.
Se o usuário deixar a caixa de seleção "Enviar relatório de erro" ativada, o Apport carregará as informações coletadas no sistema de rastreamento de bugs. Depois disso, ele abre a página de arquivamento de erros dos pacotes com um título de erro padrão sensato e deixa o restante do processo de arquivamento de erros na interface do usuário da web.
O Ubuntu recebe um número incrivelmente grande de relatórios de erros todos os dias através do nosso sistema de rastreamento de erros. Cada um deles precisa ser lido, avaliado e classificado para que possa ser corrigido. É aqui que poderíamos usar sua assistência para ajudar com erros. Para uma representação visual do processo de triagem de erros, consulte estes bons fluxogramas.
Todo relatório de bug é uma conversa com o repórter. O primeiro contato que qualquer repórter geralmente tem com a comunidade Ubuntu é através de um bug triager, que tenta elaborar um relatório completo de erros. É muito importante que demos uma boa impressão; portanto, seja educado e tente usar o seu melhor inglês.
Trabalhar em bugs simples e sem triagem é uma boa maneira de começar e familiarizar-se com o procedimento de triagem, pois você terá que lidar com todos os aspectos do ciclo de vida de um bug. A seção Erros não rastreados explica onde encontrá-los.
Tipos de Bug
Relatórios Apport
Os relatórios do Apport são erros relatados por meio do programa automatizado de relatório de erros Apport. Relatar erros usando o Apport é a maneira preferida de reportar um erro, pois fornece aos desenvolvedores muitas informações sobre o sistema afetado. Quando o Apport é usado, menos informações adicionais são necessárias, agilizando todo o processo.
Você pode reconhecer esses erros pela lista adicionada de informações do sistema em suas descrições. Alguns programas possuem ganchos para o Apport, adicionando mais informações ao relatar um bug. Essa informação geralmente pode ser encontrada nos anexos.
Bugs confirmados
Quando um bug é marcado como 'Confirmado', ele ainda não foi totalmente triado. Este bug está muito próximo de ser marcado como 'Triaged', mas você precisa ter certeza de que está pronto para os desenvolvedores corrigirem.
Solicitações de recursos
Se o relatório de erro for realmente uma solicitação de recurso, há duas possibilidades. Se o aprimoramento solicitado é pequeno e bem definido e / ou a sugestão diz respeito a um projeto upstream, a Importância do bug deve ser definida como 'Lista de Desejos'. Quando o relatório estiver concluído, o status deverá ser definido como 'Triaged'.
Somente os membros da equipe do Ubuntu Bug Control podem fazer isso. Se você não é um membro, terá que perguntar a alguém que fará isso por você. Cole o número do bug em # ubuntu-bugs e diga que acha que o bug deve estar definido como 'Wishlist'. Alguém irá notar e configurá-lo para você, embora não necessariamente imediatamente.
Como isso funciona internamente?
Interceptação de falha
O Apport usa / proc / sys / kernel / core_pattern para canalizar diretamente o dump principal no apport:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
Nota: mesmo que o ulimit esteja definido como arquivos principais desativados (especificando um tamanho de arquivo principal igual a zero usando ulimit -c 0), o apport ainda capturará a falha. Para interceptar falhas do Python, ele instala um /etc/python*/sitecustomize.pypara chamar apport em exceções não tratadas.
Exemplo
O Apport pode até capturar arquivos principais se o PID 1 (inicial) morrer:
- Se o Upstart detectar uma inconsistência interna, aumentará o sinal SIGABRT.
- O manipulador de falhas Upstart é chamado no SIGABRT.
- O manipulador de falha inicial inicia um processo filho.
- O processo filho Upstart gera novamente o sinal que resulta na saída anormal da criança.
- O kernel detecta que o processo filho saiu anormalmente e chama apport, canalizando o arquivo principal para aporta a entrada padrão (devido a / proc / sys / kernel / core_pattern).
- O apport grava o arquivo principal no disco em / var / crash /.
- O PID 1 aguarda o término do filho (o que só acontece quando o apport termina de gravar o arquivo principal).
- O PID 1 sai.
- pânico do kernel.
- Na próxima inicialização, o Whoopsie detectará o arquivo de falha e o processará.
Processo interno
Para manter o atraso e o impacto da CPU / IO o mais baixo possível, /usr/share/apport/apportapenas coleta dados que precisam ser adquiridos enquanto o processo travado ainda existe: informações sobre /proc/pido dump principal, o caminho do executável e o número do sinal. O relatório está escrito para /var/crash/executable_path.uid.crash.
Chamada de front-end
No Gnome, o update-notifier mantém uma observação inotify /var/crash. Sempre que há algo novo, ele chama / usr / share / apport / apport-checkreports. Se houver novos relatórios, ele chama / usr / share / apport / apport-gtk, que é o front-end mostrado nas capturas de tela acima.
O front-end, em seguida, coleta informações adicionais, como versões de pacotes, somas de verificação de arquivos de pacotes ou versão do SO e chama todos os ganchos de pacotes correspondentes. Para desabilitar isso, você pode executar o gsettings set com.ubuntu.update-notifier show-apport-crashes false (como seu usuário comum da área de trabalho).
Retracer automático baseado na barra de ativação
O datacenter da Canonical executa um serviço que automaticamente refaz os bugs com apport. Marcando os bugs de acordo com a arquitetura no Launchpad, um retrace será feito e a tag será removida. As tags usadas são need-i386-retrace ou need-amd64-retrace. Veja o anúncio.
Ganchos Apport por pacote
É possível que os pacotes especifiquem as informações coletadas do sistema e incluídas no relatório de erros. Isso é feito pelos ganchos apport contidos nos pacotes. Para alguns exemplos úteis, consulte:
- source_xorg.py - adiciona arquivos de log adicionais e detalhes de hardware aos relatórios de erros
- usplash - ignora falhas em caminhos de código específicos
- source_totem.py - faz perguntas ao repórter e reúne informações diferentes com base nas respostas
em / usr / share / apport / package-hooks. Há também uma lista de pacotes que fornecem ganchos de apport.
Se um relatório de falha ou bug for enviado através do apport, os ganchos relevantes serão executados automaticamente. Se você já possui um bug que foi arquivado sem apport e está interessado nas informações desses ganchos, pode pedir ao repórter do bug que use o número de bug apport-collect.
Use a fonte, Luke!
- Você pode fazer o download do tarball upstream na página do projeto Launchpad ou do tarball de origem do Ubuntu no arquivo do Ubuntu.
- O apport é desenvolvido com o bazar RCS no Launchpad. Se você quiser contribuir ou desenvolver seu próprio sistema com base nele, poderá obter sua própria ramificação com bzr get lp: apport para trunk ou debcheckout -a apport para a ramificação de pacotes do Ubuntu.
Planos futuros
Várias melhorias no desempenho, melhores ferramentas para trabalhar com relatórios e integração de mais idiomas (rastreios de pilha Mono / Python, mensagens de asserção etc.) Consulte a especificação relevante.
Fontes: Apport , Como fazer triagem e como habilitar o Apport
