Pular para o conteúdo principal

Solução de problemas

O Runner exibe o erro 404​

Como corrigir​

Recebendo o código de erro 401 do Runner

Problema de Gathering Facts para localhost​

O problema pode ocorrer no Semaphore UI instalado via Snap ou Docker.

4:10:16 PM
TASK [Gathering Facts] *********************************************************
4:10:17 PM
fatal: [localhost]: FAILED! => changed=false

Por que isso acontece​

Para mais informações sobre o uso de localhost no Ansible, leia este artigo Implicit 'localhost'.

O Ansible tenta coletar facts localmente, mas o Ansible está em um contêiner isolado e limitado que não permite isso.

Como corrigir isso​

Há duas formas:

  1. Desativar a coleta de facts:
- hosts: localhost
  gather_facts: False
  roles:
    - ...
  1. Definir explicitamente o tipo de conexão como ssh:
[localhost]
127.0.0.1 ansible_connection=ssh ansible_ssh_user=your_localhost_user

panic: pq: SSL is not enabled on the server​

Isso significa que o seu Postgres não funciona por SSL.

Como corrigir isso​

Adicione a opção sslmode=disable ao arquivo de configuração:

	"postgres": {
		"host": "localhost",
		"user": "postgres",
		"pass": "pwd",
		"name": "semaphore",
		"options": {
			"sslmode": "disable"
		}
	},

fatal: bad numeric config value '0' for 'GIT_TERMINAL_PROMPT': invalid unit​

Isso significa que você está tentando acessar por HTTPS um repositório que exige autenticação.

Como corrigir isso​

  • Vá para a tela Armazenamento de chaves.
  • Crie uma nova chave do tipo Login with password.
  • Informe o seu login do GitHub/BitBucket/etc.
  • Informe a senha. Você não pode usar a senha da sua conta do GitHub/BitBucket; em vez dela, use um Personal Access Token (PAT). Leia mais aqui.
  • Depois de criar a chave, vá para a tela Repositórios, localize o seu repositório e informe a chave.

O git clone ou pull falha de forma intermitente​

Os logs da tarefa podem exibir mensagens como Git pull failed (...), retrying in 2s, seguidas de sucesso ou de uma falha definitiva após várias tentativas.

Por que isso acontece​

O servidor git (GitHub, GitLab, Bitbucket ou uma instância self-hosted) ficou temporariamente inacessível, retornou um erro HTTP transitório, ou a rede entre o Semaphore e o servidor teve uma interrupção breve. O Semaphore repete automaticamente as operações de clone e pull antes de marcar a tarefa como falha.

Como corrigir isso​

  1. Interrupções transitórias: geralmente se resolvem sozinhas. O Semaphore tenta novamente até git_attempts vezes (padrão 4), com backoff exponencial entre as tentativas.
  2. Falhas frequentes: aumente o número de tentativas na sua configuração:
{
  "git_attempts": 8
}

Ou com uma variável de ambiente:

export SEMAPHORE_GIT_ATTEMPTS=8
  1. Falhas imediatas e constantes: as novas tentativas não vão ajudar. Verifique a URL do repositório, o nome do branch, as chaves de acesso e a conectividade de rede a partir do servidor Semaphore ou do host do runner.

Consulte Operações Git para detalhes sobre git_client e git_attempts.

A saída do script Bash está ausente ou incompleta​

Uma tarefa Bash termina com sucesso, mas o log mostra pouca ou nenhuma saída de echo, printf ou de outros comandos — especialmente quando o script termina rapidamente.

Por que isso acontece​

O Semaphore captura stdout e stderr dos comandos de shell enquanto eles são executados. Scripts muito curtos podem terminar antes que toda a saída em buffer seja lida, de modo que as últimas linhas podem ser descartadas do log da tarefa.

Como corrigir isso​

  1. Atualize: as versões recentes do Semaphore esvaziam a saída do processo antes de marcar a tarefa como concluída. Atualize o servidor e os runners se você estiver em uma versão antiga.
  2. Faça flush da saída no script quando precisar de entrega garantida:
#!/bin/bash
echo "Starting deploy"
echo "Done" >&2

Para diagnósticos críticos, grave em um arquivo dentro do workspace do repositório e use cat nele no final do script. 3. Evite saídas silenciosas antecipadas: use set -euo pipefail e mensagens de erro explícitas para que as falhas fiquem visíveis mesmo quando a saída for curta.

unable to read LDAP response packet: unexpected EOF​

Muito provavelmente, você está tentando se conectar ao servidor LDAP usando um método inseguro, embora ele espere uma conexão segura (via TLS).

Como corrigir isso​

Habilite o TLS no seu arquivo config.json:

...
"ldap_needtls": true
...

LDAP Result Code 49 "Invalid Credentials"​

Você está com a senha ou o binddn errados.

Como corrigir isso​

Use a ferramenta ldapwhoami e verifique se o seu binddn funciona:

ldapwhoami\
  -H ldap://ldap.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -x\
  -W

Ela pedirá a senha de forma interativa e deve retornar o código 0 e exibir o DN conforme especificado.

Você também pode ler os seguintes artigos:

LDAP Result Code 32 "No Such Object"​

O diretório não tem nenhuma entrada no distinguished name sobre o qual o Semaphore perguntou. Quase sempre é um ldap_searchdn errado e, com menos frequência, um ldap_binddn errado.

Como corrigir isso​

Verifique se a base de busca existe, usando as mesmas credenciais que o Semaphore usa:

ldapsearch\
  -H ldap://ldap.example.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -b "/your/ldap_searchdn/value/in/config/file"\
  -x\
  -W\
  -s base
  • O código de resultado 32 deste comando significa que a própria base não existe. Corrija ldap_searchdn no config.json; um erro de digitação em um componente, como OU=Users em vez do OU=People real, é a causa mais comum.
  • O código de resultado 0 significa que a base está correta e que o problema está em ldap_searchfilter: ele não corresponde a nenhuma entrada abaixo dessa base.

Consulte LDAP e AD para o significado de cada opção.