Диагностика и устранение проблем

Диагностика и устранение проблем — порядок проверки состояния сервера RuDesktop, сбор диагностической информации для технической поддержки и список типичных проблем с известными причинами и решениями

Базовая диагностика

Проверка статусов служб

Первый шаг при любой неполадке — убедиться, что все службы сервера запущены:

rude status

Активные службы выводятся зелёным цветом, неактивные — красным. Состав служб зависит от режима установки (INSTALL_MODE) — см. status

Если служба находится в состоянии inactive или failed, посмотрите её логи через journalctl:

journalctl -u rudesktop-web.service -n 200
journalctl -u rudesktop-relay.service -n 200
journalctl -u rudesktop-executor.service -n 200

Перезапуск сервера

Многие транзиентные проблемы (зависший воркер, исчерпание соединений) решаются перезапуском:

rude restart

Можно перезапустить только нужную службу — см. restart

Проверка логов

Все логи находятся в /var/log/rudesktop/. Состав файлов и назначение — на странице Логи сервера

Полезные команды для быстрого осмотра:

# Последние 200 строк Django-логов
tail -n 200 /var/log/rudesktop/rudesktop.log

# Логи нативных компонентов relay/rz
tail -n 200 /var/log/rudesktop/server.log

# Логи модуля выполнения политик
tail -n 200 /var/log/rudesktop/execution.log

# Слежение в реальном времени
tail -f /var/log/rudesktop/rudesktop.log

Сбор диагностики для поддержки

Команда diag собирает в один архив логи, конфиги и информацию о системе:

rude diag

Полученный архив можно передать в техническую поддержку RuDesktop по адресу support@rudesktop.ru

Важно

Перед отправкой проверьте содержимое архива — в логи могут попадать чувствительные данные (имена пользователей, IP-адреса, фрагменты SQL-запросов)

Типичные проблемы

Сервер не запускается после установки

Симптом: rude status показывает inactive или failed для одной или нескольких служб сразу после установки

Возможные причины и решения:

  • Для RPM-сборок после установки требуется выполнить переконфигурацию:

    rude reinstall

  • Порт 443 занят другим процессом. Проверьте, кто слушает порт:

    ss -tlnp | grep :443

    Решение: остановите конфликтующий сервис или смените стандартный порт

  • На ALT Server стандартный порт 443 может быть занят системными службами — при rude reinstall укажите другой порт:

    rude reinstall server.example.com:8443

Ошибка PAM account manager при создании суперпользователя на Astra

Симптом: при выполнении rude createsuperuser на Astra Linux SE 1.7/1.8 появляется ошибка PAM account manager

Причина: включены механизмы МКЦ и МРД, блокирующие создание учётной записи

Решение: временно отключите МКЦ и МРД — см. Установка сервера на Astra с МКЦ

Ошибка лицензионного ключа при обновлении

Симптом: при обновлении на новую версию (например, с 2.8 на 2.9) возникает ошибка несоответствия лицензионного ключа, после чего происходит откат

Причина: ключ выпущен под старую версию

Решение:

  1. Запросите новый ключ у отдела продаж (sales@rudesktop.ru) или у вашего менеджера

  2. Обновите лицензию на странице Лицензия

  3. Повторите процедуру обновления

Подробнее — Установка/обновление сервера

Клиенты не могут подключиться после смены IP или сертификата

Симптом: клиенты RuDesktop перестали подключаться после rude reinstall или ручной смены сертификата

Причина: после rude reinstall создаётся новый корневой CA, и клиенты теряют доверие к серверу

Решения:

  • Если используется собственный центр сертификации — повторно опубликуйте сертификат на устройствах

  • Если используется встроенный CA RuDesktop — клиенты должны переустановить доверие к серверу. Передайте им новый адрес сервера или используйте автоматическое переподключение

Важно

Перед rude reinstall рекомендуется сделать резервную копию /var/lib/rudesktop/ca/ — иначе старые сертификаты будут потеряны

Точка распространения не получает задачи

Симптом: на странице «Очередь задач» в колонке «Точка распространения» название узла не отображается, политики выполняются на главном сервере

Возможные причины:

  • На точке распространения не настроены REDIS_URL и параметры POSTGRES_* в /etc/default/rudesktop

  • Узел не может достучаться до Redis главного сервера (закрыт файрволом, неверный пароль)

  • Версии сервера на главном узле и точке распространения не совпадают

Диагностика: проверьте подключение к Redis с точки распространения — см. раздел «Проверка доступности Redis» на странице Настройка точек распространения

Ошибки подключения к Redis или PostgreSQL

Симптом: в логах server.log или rudesktop.log появляются ошибки соединения с Redis/PostgreSQL

Что проверить:

  • Доступность сервиса:

    redis-cli -h <host> -p <port> -a <password> PING
PGPASSWORD=<password> psql -h <host> -p <port> -U <user> -d <db> -c "SELECT 1"

  • Файрвол — порты Redis (32459 для встроенного) и PostgreSQL (5432) должны быть открыты с узлов RuDesktop

  • Аутентификация — для внешнего Redis обязательно установите requirepass, для PostgreSQL добавьте правило в pg_hba.conf

  • Параметры в ``/etc/default/rudesktop`` — переменные REDIS_URL и POSTGRES_* должны указывать на правильные адреса

Подробнее — Настройка Redis, Настройка подключения и SSL для сторонней БД

Не уходят события в SIEM

Симптом: настроены SYSLOG_HOST / SYSLOG_PORT, но в SIEM события не приходят

Что проверить:

  1. Включены ли тумблеры на странице Настройки → блок «Настройки логов». По умолчанию все выключены — даже после настройки SYSLOG_HOST ни одного события не уйдёт

  2. Локальный syslog-демон принимает подключения по TCP (rsyslog или syslog-ng) — см. Настройка отправки событий в SIEM-систему

  3. Файрвол между RuDesktop и SIEM-приёмником

  4. Перезапуск сервера после изменения настроек — rude restart

Сервер тормозит, медленный отклик веб-интерфейса

Что проверить:

  • Свободное место на диске — особенно в каталогах /var/lib/rudesktop/ (медиа, kickstart, PXE) и /var/log/rudesktop/ (логи)

  • IOPS дисковой подсистемы — должна обеспечивать минимум 1000 IOPS на 5000 пользователей (см. Системные требования)

  • Количество воркеров Gunicorn — параметр GUNICORN_WORKERS в /etc/default/rudesktop (см. Настройка Gunicorn)

  • Очередь задач в Redis — большое количество накопленных задач может тормозить executor

  • Текущие SQL-запросы — команда prof показывает запросы, выполняющиеся в данный момент

Каталог логов разрастается

Симптом: /var/log/rudesktop/ занимает много места

Решение:

  • Команда maintain запускается по расписанию политикой «Обслуживание сервера» и удаляет архивы старше 30 дней. Если она не запущена — выполните вручную:

    rude maintain

  • Сократите срок хранения архивов:

    rude maintain --log-delete-after-days 7

  • Понизьте уровень логирования с DEBUG (по умолчанию) до INFO или WARNING — см. Настройка уровня логирования

Очистка старых записей в БД

Со временем в базе накапливаются записи аудита, журналы задач, неактуальные устройства. Для регламентной очистки используйте:

  • clean_audit_logs — удаление старых записей аудита

  • clean_job_logs — удаление старых логов задач

  • delete — удаление неактивных устройств

Проблемы с PXE-загрузкой

Симптом: клиент пытается загрузиться по сети, но не получает образ

Что проверить:

  • Опубликован ли образ ОС в веб-интерфейсе на странице Образы OS — служба rudesktop-pxe запускается автоматически только при наличии активного образа

  • DHCP-сервер сети правильно передаёт PXE-опции (см. Конфигурация для MikroTik, Конфигурация для DHCPD)

  • Размер блока TFTP — в сложных сетях с фрагментацией пакетов уменьшите TFTP_BLOCK_SIZE_LIMIT до 512 (см. Настройка размера блока TFTP)

  • Архитектура клиента — ipxe.efi для UEFI x64, ipxe-arm64.efi для UEFI ARM64, undionly.kpxe для Legacy BIOS

Когда обращаться в поддержку

Если после применения подходящего решения проблема сохраняется:

  1. Соберите диагностику: rude diag

  2. Зафиксируйте время возникновения проблемы и точные шаги воспроизведения

  3. Укажите версию сервера: rude relay --version

  4. Опишите симптомы и приложите архив диагностики

  5. Отправьте письмо в техническую поддержку RuDesktop по адресу support@rudesktop.ru