Перейти к основному содержимому

Устранение неполадок

Runner выдаёт ошибку 404​

Как исправить​

Getting 401 error code from Runner

Проблема Gathering Facts для localhost​

Проблема может возникать в Semaphore UI, установленном через Snap или Docker.

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

Почему это происходит​

Подробнее об использовании localhost в Ansible читайте в статье Implicit 'localhost'.

Ansible пытается собрать факты локально, но Ansible находится в ограниченном изолированном контейнере, который этого не позволяет.

Как это исправить​

Есть два способа:

  1. Отключить сбор фактов:
- hosts: localhost
  gather_facts: False
  roles:
    - ...
  1. Явно задать тип подключения ssh:
[localhost]
127.0.0.1 ansible_connection=ssh ansible_ssh_user=your_localhost_user

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

Это означает, что ваш Postgres не работает по SSL.

Как это исправить​

Добавьте параметр sslmode=disable в файл конфигурации:

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

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

Это означает, что вы пытаетесь получить доступ по HTTPS к репозиторию, который требует аутентификации.

Как это исправить​

  • Перейдите на экран Хранилище ключей.
  • Создайте новый ключ типа Login with password.
  • Укажите ваш логин для GitHub/BitBucket и т. д.
  • Укажите пароль. Для GitHub/BitBucket нельзя использовать пароль от учётной записи — вместо него следует использовать Personal Access Token (PAT). Подробнее здесь.
  • После создания ключа перейдите на экран Репозитории, найдите ваш репозиторий и укажите ключ.

Git clone или pull периодически завершается ошибкой​

В логах задач могут появляться сообщения вроде Git pull failed (...), retrying in 2s, за которыми следует либо успех, либо окончательная ошибка после нескольких попыток.

Почему это происходит​

Git-сервер (GitHub, GitLab, Bitbucket или self-hosted экземпляр) был временно недоступен, вернул временную HTTP-ошибку, либо в сети между Semaphore и сервером произошёл кратковременный сбой. Semaphore автоматически повторяет операции clone и pull, прежде чем пометить задачу как неудачную.

Как это исправить​

  1. Временные сбои: обычно проходят сами. Semaphore повторяет попытки до git_attempts раз (по умолчанию 4) с экспоненциальной задержкой между попытками.
  2. Частые сбои: увеличьте количество попыток в конфигурации:
{
  "git_attempts": 8
}

Или через переменную окружения:

export SEMAPHORE_GIT_ATTEMPTS=8
  1. Немедленные, постоянные сбои: повторные попытки не помогут. Проверьте URL репозитория, имя ветки, ключи доступа и сетевую доступность с сервера Semaphore или хоста runner’а.

Подробнее о git_client и git_attempts см. в разделе Операции Git.

Вывод Bash-скрипта отсутствует или неполный​

Bash-задача завершается успешно, но в логе почти нет вывода от echo, printf или других команд — особенно когда скрипт завершается быстро.

Почему это происходит​

Semaphore перехватывает stdout и stderr shell-команд во время их выполнения. Очень короткие скрипты могут завершиться раньше, чем будет прочитан весь буферизованный вывод, поэтому последние строки могут не попасть в лог задачи.

Как это исправить​

  1. Обновитесь: свежие версии Semaphore дочитывают вывод процесса, прежде чем пометить задачу завершённой. Обновите сервер и runner’ы, если вы используете старый релиз.
  2. Сбрасывайте буфер вывода в скрипте, когда нужна гарантированная доставка:
#!/bin/bash
echo "Starting deploy"
echo "Done" >&2

Для критически важной диагностики записывайте данные в файл внутри рабочей области репозитория и выводите его через cat в конце скрипта. 3. Избегайте тихого раннего выхода: используйте set -euo pipefail и явные сообщения об ошибках, чтобы сбои были видны даже при скудном выводе.

unable to read LDAP response packet: unexpected EOF​

Скорее всего, вы пытаетесь подключиться к серверу LDAP небезопасным способом, тогда как он ожидает защищённое соединение (через TLS).

Как это исправить​

Включите TLS в файле config.json:

...
"ldap_needtls": true
...

LDAP Result Code 49 "Invalid Credentials"​

У вас неверный пароль или binddn.

Как это исправить​

Используйте утилиту ldapwhoami и проверьте, работает ли ваш binddn:

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

Она интерактивно запросит пароль и должна вернуть код 0 и вывести указанный DN.

Также вы можете прочитать следующие статьи:

LDAP Result Code 32 "No Such Object"​

В каталоге нет записи с тем distinguished name, который запросил Semaphore. Почти всегда причина — неверный ldap_searchdn, реже — неверный ldap_binddn.

Как это исправить​

Проверьте, что база поиска существует, используя те же учётные данные, что и Semaphore:

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
  • Код результата 32 от этой команды означает, что самой базы не существует. Исправьте ldap_searchdn в config.json; обычная причина — опечатка в компоненте, например OU=Users вместо фактического OU=People.
  • Код результата 0 означает, что с базой всё в порядке, а проблема в ldap_searchfilter: он не находит ни одной записи ниже этой базы.

Значение каждой опции см. в разделе LDAP и AD.