As informações ou relatórios coletados são enviados para um sistema de acompanhamento de bugs.
Se algum processo no sistema for interrompido devido a um sinal comumente
referido como 'crash' (violação de segmentação, erro de bus, flutuação
ponto de exceção, etc.), ou e. g. um aplicativo em Python empacotado gera
uma exceção não identificada, o backend apport é automaticamente chamado.
Produz um relatório de falha inicial em um arquivo em / var / crash / (o arquivo
nome é composto pelo nome do executável com falha e pelo usuário
identidade). Se o processo travado pertencer ao usuário que está atualmente
logado, ou pertence a um processo do sistema e o usuário é um
administrador, apport informa o usuário sobre o acidente e se oferece para
relatar o problema.
Se o usuário deixar a caixa de seleção "Enviar relatório de erros" ativada,
carrega as informações coletadas no sistema de rastreamento de bugs. Depois
que abre a página de arquivamento de erros dos pacotes com um padrão sensível
título do bug e deixa o resto do processo de arquivamento do bug 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 bugs. Cada um deles precisa ser lido, avaliado e classificado para que possa ser corrigido. É aqui que podemos usar sua ajuda para ajudar com bugs. Para uma representação visual do processo de triagem de erros, veja estes gráficos de fluxo agradáveis.
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 triager de bug, que tenta montar um relatório de bug completo. É muito importante dar uma boa impressão, por isso, seja educado e tente usar o seu melhor inglês.
Trabalhar com bugs simples e não treinados é 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 Untriaged bugs explica onde encontrá-los.
Tipos de bugs
Apresentar relatórios
Os relatórios do Apport são erros reportados através do programa automatizado de relatórios de erros Apport. Relatar erros usando o Apport é a maneira preferida de relatar um bug, pois fornece aos desenvolvedores muitas informações sobre o sistema afetado. Quando o Apport é usado, menos informações adicionais são necessárias, acelerando todo o processo.
Você pode reconhecer esses bugs pela lista adicionada de informações do sistema em sua descrição. Alguns programas possuem ganchos para o Apport, adicionando mais informações ao relatar um bug. Essas informações geralmente podem ser encontradas nos anexos.
Erros confirmados
Quando um bug é marcado como "Confirmado", ainda não está totalmente triado. Esse bug está muito perto de ser marcado como "Triaged", mas você precisa ter certeza de que está pronto para os desenvolvedores consertarem.
Solicitações de recursos
Se o relatório de erros for realmente uma solicitação de recurso, existem duas possibilidades. Se o aprimoramento solicitado for pequeno e bem definido e / ou a sugestão se referir 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 deve ser definido como "Triagem".
Apenas os membros da equipe de Controle de Erros do Ubuntu podem fazer isso. Se você não é um membro, terá que pedir a alguém que o faça por você. Cole o número do bug em # ubuntu-bugs e diga que você acha que o bug deve estar definido como 'Wishlist'. Alguém vai notar e definir para você, embora não necessariamente imediatamente.
Como funciona internamente?
Interceptação de falha
O Apport usa / proc / sys / kernel / core_pattern para enviar diretamente o dump principal para o apport:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
Nota: mesmo que o ulimit esteja configurado para desabilitar os arquivos principais (especificando um tamanho de arquivo do núcleo igual a zero usando ulimit -c 0), o apport ainda capturará a falha.
Para interceptar falhas do Python, ele instala um /etc/python*/sitecustomize.py para chamar o apport em exceções não tratadas.
Exemplo
O Apport pode até capturar arquivos principais se o PID 1 (Upstart) morrer:
- Se o Upstart detecta uma inconsistência interna, ele aumenta o SIGABRT
sinal.
- O manipulador de falhas do Upstart é chamado no SIGABRT.
- O manipulador de falhas de inicialização avançada bifurca um processo filho.
- O processo filho Upstart reaumenta 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 a entrada padrão do apports (devido a / proc / sys / kernel / core_pattern).
- o apport grava o arquivo principal no disco em / var / crash /.
- O PID 1 aguarda que seu filho termine (o que só acontece quando o apport termina de gravar o arquivo principal).
- PID 1 sai.
- pânico do kernel.
- Na próxima inicialização, o Whoopsie detectará o arquivo de falha e o processará.
Backend
Para manter o atraso e o impacto da CPU / IO o mais baixo possível, /usr/share/apport/apport apenas coleta dados que precisam ser adquiridos enquanto o processo travado ainda existe: informações de /proc/pid , o dump principal, o caminho do executável e o número do sinal. O relatório é gravado em /var/crash/executable_path.uid.crash .
Invocação de frontend
No Gnome, o update-notifier mantém um relógio inotify em /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 frontend mostrado nas capturas de tela acima.
O front-end então coleta informações adicionais, como versões de pacotes, checksums 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 de desktop).
Auto-retracer baseado em Launchpad
O centro de dados da Canonical executa um serviço que rastreia automaticamente os bugs com um dado. 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 do Apport por pacote
É possível que os pacotes especifiquem informações coletadas do sistema e incluídas no relatório de erros. Isso é feito pelos hooks contidos nos pacotes. Para alguns exemplos úteis, veja:
- source_xorg.py - adiciona arquivos de log adicionais e detalhes de hardware
relatórios de bugs
- usplash - ignora falhas em caminhos de código específicos
- source_totem.py - faz perguntas ao repórter e reúne diferentes
informação baseada em respostas
em / usr / share / apport / package-hooks. Há também uma lista de pacotes que fornecem ganchos de acesso.
Se um relatório de falha ou bug for enviado através do apport, os ganchos relevantes serão executados automaticamente. Se você tem um bug já reportado que foi arquivado sem um dado, e você está interessado nas informações desses ganchos, você pode pedir ao repórter de bug para usar o número do bug apport-collect.
Use a fonte, Luke!
- Você pode fazer o download do tarball upstream do projeto Launchpad
página, ou o tarball de origem do Ubuntu a partir do arquivo Ubuntu.
O - apport é desenvolvido com o bazar RCS no Launchpad. Se você quiser
contribuir para isso ou desenvolver seu próprio sistema baseado nele, você pode obter
seu próprio branch com bzr get lp: apport para trunk, ou debcheckout -a
para o ramo de empacotamento do Ubuntu.
Planos futuros
Várias melhorias no desempenho, melhores ferramentas para trabalhar com relatórios e integração de mais idiomas (rastreamentos de pilha do Mono / Python, mensagens de asserção, etc.) Consulte a especificação relevante.
Fontes: Suporte , Como fazer triagem e Como habilitar o Apport
