по ssh. В логах пусто, динамика не прослеживается, ошибок никаких нет, но по ssh не пускат:
ssh -T git@gitlab.example.com
shell request failed on channel 0
Ребут puma спасает ситуацию, однако ненадолго 2-10 часов. Пока выявить что именно вызывает проблемы тоже не удается. Кто-то сталкивался? Есть ли какие-то рекомендации куда посмотреть может, где-то какие-то расширенные логи можно вытащить?
Если прочитать документацию вендора с описанием архитектуры, то станет понятно, как вообще соотносятся пума и доступ по SSH.
для тех кто будет искать в чатике (как я искал). Проблемы которые я раскурил: 1. sshd не был настроен для пользователя git по лучшим практикам для authorized keys (https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html#with-openssh). Без этой настройки gitlab-shell переставал писать в лог, и дальнейшний анализ был затруднен. После этой настройки логи продолжали валиться после остановки сервиса. 2. После выполнения пункта 1, продолжил поиски заветных ошибок и они оказались в /var/log/secure, хотя без устранения пункта 1 там было пусто (без ошибок), что уперлись в лимиты. error: do_exec_no_pty: fork: Resource temporarily unavailable Поднял лимиты по файлам, почитал статью и обнаружил, что на самом деле уперлись в лимиты по процессам. (https://access.redhat.com/solutions/22105) под git 3800 процессов было puma workers и в сумме уперлись в лимит 4096. Снизил в 4 раза (?) количество процессов и тредов: puma['worker_processes'] = 2->1 puma['min_threads'] = 4->2 puma['max_threads'] = 4->2 Сейчас количество процессов под пумой держится в районе 64, а под git 844. Дальше по планам: 1. вернуть процессы на 1->2 2. если снова потекут, то через strace смотреть в корень проблемы. (https://docs.gitlab.com/ee/administration/operations/puma.html#gitlab-api-is-not-accessible) Что странно: проблемы начались после обновления на 16.3. Да, раскурил с помощью схемы, спасибо :) https://docs.gitlab.com/ee/development/architecture.html
Обсуждают сегодня