Инструменты пользователя

Инструменты сайта


sharixopen:knowledge:operations:runtime_health

Это старая версия документа!


Health, systemd, handlers и многократные установки

Тип: verification · Статус: сведения требуют сверки с действующей установкой; архитектурные правила сформулированы как целевой контракт.

Раздел: Эксплуатация Open и наблюдаемость

Имя экземпляра

Один installation identity определяет имя основного systemd unit и шаблона handler. Несколько установок на одном сервере должны иметь читаемые независимые имена, без случайных hash-суффиксов.

Наблюдаемость

active systemd не доказывает готовность обработчиков. Нужны runtime evidence: регистрация handler, связь XMPP, корректный endpoint и тестовый путь события. STARTING означает отсутствие подтверждения, DEGRADED — обнаруженный сбой; состояние не маскируется.

Безопасное обновление

Установка и обновление обязаны воспроизводить конфигурацию из текущих профилей, не переименовывать работающие units наугад и сохранять обратимый путь восстановления.

Связанные понятия

Отказ после deploy: не повторять весь installer

deploy restart failed означает: подготовка могла завершиться, но runtime не прошёл проверку. Сначала читать journal своей установки и проверить bind/port; не повторять pip/migrate/seed/LDAP ради того же запуска. В примере namespace opensharix; заменить на реальный SYSTEMD_SERVICE_NAME:

systemctl status opensharix.service --no-pager
journalctl -u opensharix.service -b -n 150 --no-pager -o short-iso
ss -ltnp

Журнал может содержать персональные данные/секреты сторонних библиотек: перед передачей очищать, не включать shell xtrace. Deploy читает журнал после root bootstrap с journal opt-in и нового login; доступ host-wide, не только свой unit. После исправления причины — только ./bin/install.sh restart от deploy.

Типовые причины и точная граница ремонта

Симптом Проверка / действие
Permission denied на env или state Проверить canonical path, traversal и named ACL; root activate проверяет Django именно под runtime. Не открывать весь conf-real и backups.
Нельзя создать/rotаte LDAP log Отдельный /var/log/<namespace>/django-ldap.log, доступы deploy/runtime, lock и rollover. Не общий /var/log/django-ldap.log.
200 CSS, но 502 страницы Nginx static работает независимо; проверить процесс приложения, bind/upstream и журнал.
В браузере без стилей только при DEBUG=False Проверить collectstatic, Content-Type и выбранный nginx vhost/include; не включать DEBUG как исправление.
venv moved/foreign activation Read-only venv_paths.py, затем только явный rebuild остановленной установки; не ручная замена shebang во всём venv.
slappasswd not found из deploy Новый login/PATH с /usr/sbin и LDAP prerequisite; не давать root ради поиска binary.
sudo: Permission denied на ALT Bootstrap готовит exact executable ACL при host wheelonly, без добавления deploy в wheel.
visudo отклоняет 99-sudopw Это сторонний OS файл; администратор проверяет owner/mode/ACL и visudo -c. Installer не должен сам переписывать чужое правило.
Git dubious ownership Работать владельцем checkout, проверить ownership; не использовать global safe.directory=*.

Runtime startup не нормализует конфигурацию, не выполняет migrate/seed/collectstatic и не чинит source permissions; drift/static gates остаются fail-visible. Activate сверяет управляемые пути и actual runtime Django checks до регистрации grants. Restart проверяет main/configured handlers/disabled states/static; это не доказательство успешного XMPP или пользовательского бизнес-действия. Не стартовать manual/disabled handlers массовой командой с wildcard.

Обратная связь после Testopen

Указать безопасные SHA/ветки owners, Unix roles/namespace, выбранные phases/flags, nginx=0/1, результат HTML/CSS при DEBUG=False, Git author, права env hidden/read/write, main/handler process state и functional health. Приложить только очищенные фрагменты первой причины. Остановка по ошибке — корректный fail-visible результат, не повод ослабить guard. Соседний production не изменять ради теста.

Проверенная реализация и границы доказательств

Сверено 2026-10-27 по опубликованному Open root ec9bf2a и Open config 84597d4. Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py, deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git. Владелец подтвердил успешный запуск Open после исправлений. Установка nginx с новым вопросом и повторная независимая проверка Testopen ещё требуют отдельной host-приёмки. Это не объявление релиза и не подтверждение production. Редакционный status=review относится к статье, не к наличию реализации.

sharixopen/knowledge/operations/runtime_health.1793088196.txt.gz · Последнее изменение: — sx_knowledge_api_open

© 2022 ShariX