Эта страница поможет, если не открывается веб-интерфейс,
/healthне отвечает или сообщаетdown, Ринго перестал работать целиком или неполадки начались после изменений на сервере.
Ринго работает в контейнерах Docker, конфигурация находится в /etc/ringo (docker-compose.yml и .env). Это контейнеры backend и базы данных, а также встроенный nginx-proxy с letsencrypt или ваш внешний прокси. Подробнее о компонентах см. Как устроен Ринго.
.env контейнеры не были пересозданы.curl -s https://<домен>/health
docker ps -a --format 'table {{.Names}}\t{{.Status}}'
Ожидаемый результат: контейнеры roll-deploy-backend и roll-deploy-db в состоянии Up, без частых перезапусков (Restarting). При встроенном прокси работают также контейнеры …-nginx-proxy-… и …-letsencrypt-… (точные имена зависят от проекта Compose). Если в списке есть roll-deploy-micromdm, у вас устаревшая версия: в 2.4.4 и 3.0.5 этого контейнера нет.
| Результат | Что делать |
|---|---|
Контейнер backend в состоянии Exited (1) |
Сначала сохраните лог (см. ниже), затем выполните docker start roll-deploy-backend. |
Контейнер постоянно перезапускается (Restarting) |
Выполните docker logs --tail 100 <контейнер>: в логе будет ошибка запуска (нет базы данных, нет места, ошибка конфигурации). |
/health сообщает, что db в состоянии down |
Выполните docker logs --tail 100 roll-deploy-db и проверьте свободное место на диске. |
/health не отвечает, хотя контейнеры в состоянии Up |
Проверьте, что прокси перенаправляет запросы на порт 5000. На сервере выполните curl -s http://127.0.0.1:5000/health. |
Как остановленный backend выглядит снаружи. При встроенном nginx-proxy это проявляется не как ошибка 502, а как проблема с сертификатом: прокси перестаёт обслуживать сайт остановленного контейнера, по HTTPS отдаётся самоподписанный сертификат, а по HTTP возвращается 503. Если ошибка сертификата появилась сразу у всех, проверьте docker ps -a до того, как проверять сертификат.
Почему backend не запустился автоматически. Если в docker-compose.yml для сервиса backend не задан параметр restart (так бывает в установках по старым инструкциям; у прокси он обычно задан), после аварийного завершения backend остаётся остановленным, пока его не запустят вручную. Проверьте: docker inspect roll-deploy-backend --format '{{.HostConfig.RestartPolicy.Name}}'; значение no означает, что перезапуска нет. Чтобы backend перезапускался автоматически, выполните:
docker update --restart unless-stopped roll-deploy-backend
# или добавьте в docker-compose.yml для сервиса backend: restart: unless-stopped
Сохраните лог до перезапуска. Причина остановки записана в конце лога контейнера, а при пересоздании контейнера лог удаляется:
docker logs -t roll-deploy-backend > ~/backend-crash.log 2>&1
tail -40 ~/backend-crash.log
dmesg -T | grep -iE 'oom|killed process' | tail # не завершила ли система процесс из-за нехватки памяти
| Признак | Причина |
|---|---|
В конце лога npm error signal SIGKILL, а в dmesg — Out of memory: Killed process … (node) |
Системе не хватило памяти, и она завершила backend. Минимальные требования к серверу указаны в системных требованиях. |
Рекомендуется добавить /health в систему мониторинга (например, Zabbix) и проверять значения jq -r '.status' и jq -r '.details.db.status' (ожидаются ok и up). Проверяйте /health снаружи: мониторинг с того же сервера не обнаружит проблему с прокси.
df -h / /var/lib/docker
docker inspect roll-deploy-backend --format '{{.HostConfig.LogConfig.Type}}' # куда записываются логи контейнеров
json-file (используется в Docker по умолчанию, в том числе в поставке Ринго) хранит логи контейнеров без ротации, и со временем они занимают весь диск. Посмотрите размер логов: du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Чтобы сразу освободить место, выполните truncate -s 0 /var/lib/docker/containers/<id>/<id>-json.log. Чтобы проблема не повторилась, задайте параметры logging: options: max-size и max-file в docker-compose.yml.journald (если он задан в docker-compose.yml в блоке logging: driver: journald) ограничивает размер самостоятельно. Занятое место показывает journalctl --disk-usage, очистку выполняет journalctl --vacuum-size=500M, предельный размер задаётся параметром SystemMaxUse= в /etc/systemd/journald.conf.Команды
truncateиjournalctl --vacuum-*удаляют логи без возможности восстановления. Если вы расследуете инцидент, сначала сохраните нужный период:docker logs -t --since <время> roll-deploy-backend > ~/backend-incident.log 2>&1.
Проверьте также размер файлов логов backend внутри контейнера (по одному файлу в сутки): docker exec roll-deploy-backend du -sh /logs. Статистика хранения данных и автоматическая очистка устаревших записей в базе находятся в разделе Настройки → Обслуживание базы данных.
Адрес сервера записан в .env (HOST_DOMAIN, PUBLIC_URL) и в профилях уже зарегистрированных устройств.
При пересоздании контейнеров (шаг 2) удаляются логи контейнеров и файлы
/logsвнутри backend. Если они нужны для расследования, сохраните их заранее (см. Обращение в поддержку).
Измените HOST_DOMAIN и PUBLIC_URL в /etc/ringo/.env.
Пересоздайте контейнеры. Обычный перезапуск не применяет изменения .env:
cd /etc/ringo && docker compose up -d --force-recreate
Обновите TLS-сертификат и записи DNS для нового домена.
Устройства, зарегистрированные на старый адрес, продолжают обращаться к нему (на Mac адрес виден в выводе profiles status -type enrollment, строка MDM server:). Зарегистрируйте их заново.
timedatectl # System clock synchronized: yes
date -u
Срок действия сертификатов, которые Ринго выдаёт по SCEP, отсчитывается от времени сервера, а задания по расписанию выполняются по его часам. Если время неверное, выданный сертификат может оказаться на устройстве ещё не действующим, а задания выполняются не вовремя. Включите синхронизацию времени: timedatectl set-ntp true.
Задания по расписанию выполняются по часам контейнера backend, которые идут в UTC независимо от часового пояса сервера. Поэтому команды SecurityInfo появляются в списке в 03:00 и 15:00 по Москве (см. Как устроен Ринго → расписание).
Согласно системным требованиям, оптимальная нагрузка — до 300 устройств на сервер. Одновременно обрабатывается около 200 MDM-команд и около 20 политик, остальные ожидают в очереди. Если при большем количестве устройств интерфейс работает медленно, а команды доставляются долго, серверу требуется масштабирование; это не сбой.
При обновлении контейнеры пересоздаются, поэтому логи старых контейнеров и файлы /logs внутри backend удаляются. Если вы расследуете инцидент, соберите логи до обновления (см. Обращение в поддержку). После обновления проверьте версию в разделе Настройки → Информация о системе.
Файл /etc/ringo/.env содержит пароли базы данных и администратора, а также ключ подписи токенов. Ограничьте доступ к нему и к key.json только пользователем root:
chmod 600 /etc/ringo/.env /etc/ringo/key.json
Обратитесь в техническую поддержку (см. Обращение в поддержку).
Проверено на Ринго 3.0.5, октябрь 2026. Тексты ошибок — Справочник ошибок, термины — Термины.