8. Monitorando a Compilação
Anterior |  | Próxima

## 8. Monitorando a Compilação

Você pode usar o comando `qclient` para monitorar o status dos nós de compilação, e para listar as tarefas de compilação agendadas para execução:

`python `path`/qmanager/qclient jobs`

`python `path`/qmanager/qclient status`

O comando `scripts/stats `${branch}`` mostra o número de pacotes cuja compilação já finalizou.

A execução de um `cat /var/portbuild/*/loads/*` irá mostrar o `load` nos clientes e o número de compilações simultâneas em andamento. Os arquivos que foram atualizados recentemente correspondem aos clientes que estão `online`; os demais arquivos são dos clientes que estão `offline.`

### Nota:

O comando `pdispatch` faz o envio de trabalhos para o cliente, e executa tarefas de pós-processamento a partir do retorno recebido do client. O `ptimeout.host` monitora permanentemente o processo de compilação e a encerra após a ocorrência de `timeouts`. Desta forma, se você tiver 50 processos `pdispatch`, mas apenas 4 processos ssh(1), significa que 46 processos `pdispatch`es estão ociosos, esperando que um nó fique livre.

Executar `tail -f `${arch}`/`${branch}`/build.log` irá mostrar o progresso geral da compilação.

Se a compilação do `port` falhar, e o motivo não ficar imediatamente óbvio a partir da análise do `log`, você pode preservar o `WRKDIR` para uma análise mais aprofundada. Para fazer isso, crie um arquivo vazio chamado `.keep` no diretório do `port`, isso vai arquivar, comprimir, e copiar o `WRKDIR` para ``${arch}`/`${branch}`/wrkdirs`.

Se você verificar que o sistema está compilando o mesmo pacote de forma ciclica, repetindo o processo indefinidamente, você pode ser capaz de corrigir o problema reconstruindo manualmente o pacote ofensor.

Se todas as compilações iniciam reclamando de que não pode carregar os pacotes dos quais ela depende, verifique se o httpd ainda está rodando, e o i reinicie se não estiver.

Mantenha o olho na saída do df(1). Se o sistema de arquivos do `/var/portbuild` ficar cheio, coisas ruins acontecem.

O status de todas as compilações é gerado duas vezes por hora e postado em http://pointyhat.FreeBSD.org/errorlogs/packagestats.html. Para cada `buildenv` é apresentado o seguinte:

- `cvs date` é o conteúdo do `cvsdone`. É por isso que nós recomendamos que você atualize o `cvsdone` para executar compilações experimentais, `-exp` (veja abaixo).

- data do último `log` (`latest log`)

- número de linhas no `INDEX`

- o número atual de `logs` de compilações (`build logs`)

- o número de pacotes concluídos (`packages`)

- o número de erros (`errors`)

- o número de `ports` ignorados (duds) (listados como `skipped`)

- A coluna `missing` mostra a diferença entre o `INDEX` e as outras colunas. Se você reiniciou uma compilação após um `cvs update`, provavelmente haverá duplicatas nos pacotes e colunas de erros, e esta coluna será inútil. (O `script` é ingênuo).

- Os valores das colunas `running` e `completed` são palpites baseados em um grep(1) do `build.log`.

Anterior |  | Próxima
7. Manutenção da Compilação | Principal | 9. Lidando com Erros de Compilação

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.