7. Устранение неисправностей

Симптом Пользователь отправил документ на печать, но задание не появляется в разделе Управление → Задания и на МФУ. Условия возникновения Используется клиент ПринтМенеджер на Windows или Linux Печать выполняется через принтер Printum Диагностика Шаг 1. Проверить статус службы клиента ПМ Windows: Win+R → eventvwr → Журналы Windows → Приложение → источник ПринтМенеджер Client . Найти ошибки (красные/жёлтые записи). Linux: sudo systemctl status printum-printmanager-client.service sudo journalctl -u printum-printmanager-client.service Шаг 2. Типовые ошибки в логах | Ошибка | Причина | Решение | | ------------------------------------------ | ------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | No user {'login'} is authorized | Пользователь не найден в системе или неверный SID | Убедитесь, что пользователь существует в Printum и имеет правильный SID. Проверьте access_token. | | HTTPSConnectionPool: Max retries exceeded | Клиент ПМ не может подключиться к серверу | Проверьте доступность сервера ПринтМенеджер с рабочей станции. | | LookupAccountName: доверительные отношения | Рабочая станция не в домене | Проверьте подключение к домену. Для локальных УЗ: убедитесь, что пользователь в WORKGROUP. | | AssertionError: Adding printer Printum | Принтер Printum не найден или неверный драйвер | Удалите принтер Printum вручную и переустановите клиент ПМ. | Шаг 3. Проверить наличие принтера Убедитесь, что в системе присутствует виртуальный принтер с именем Printum и он использует драйвер Printum XPS. Что проверить перед эскалацией Логи клиента ПринтМенеджер без ошибок Служба клиента запущена Принтер Printum присутствует на АРМ Пользователь существует в Printum Логи и диагностические данные Где смотреть логи Клиент ПМ Windows — Отправка заданий на печать на ОС Windows Откройте eventvwr → Журналы Windows → Приложение → источник Print Manager Client Клиент ПМ Linux — Отправка заданий на печать на ОС Linux sudo journalctl -u printum-printmanager-client.service printmanager-app — Основной контейнер ПринтМенеджер — обработка HTTP-запросов, приём заданий от клиентов cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app Что искать в логах Выявить ошибки запуска сервиса клиента ПМ. Выявить ошибки передачи данных от клиента на сервер. Выявить ошибки обработки API-запросов в printmanager-app. Определить причины возврата кодов 4xx/5xx. Что приложить к обращению в поддержку Логи клиента ПМ: Windows — Просмотр событий ( eventvwr ) → Журналы Windows → Приложение → источник Print Manager Client ; Linux — sudo journalctl -u printum-printmanager-client.service Версию ПринтМенеджера: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС рабочей станции и сервера Связанные страницы Задание не распечатывается на принтере Принтеры не появляются на рабочей станции

Проблемы печати

Документы печатаются с обрезанными краями

Симптом При печати или копировании края документа обрезаются. Причина Принтеры имеют непечатаемые поля. Стандартное поведение — печать с обрезанием краёв. Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — обработка параметров печати, масштабирование cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-cups — Сервер печати CUPS — выполнение задания с указанными параметрами cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-cups Что искать в логах Выявить ошибки обработки параметров задания (масштабирование, поля). Определить, на каком этапе происходит ошибка (валидация / логика / CUPS). Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Включить масштабирование FIT_TO_PAGE Откройте панель администратора ПринтМенеджера. Перейдите в Настройки → Настройки печати . Установите галочку у переменной FIT_TO_PAGE . После этого изображения будут масштабироваться по размерам печатаемого листа. Для Xerox Global Print Driver PS (бесклиентская печать) В списке принтеров выберите принтер для бесклиентской печати → Свойства принтера → Настройки . Перейдите на вкладку «Дополнительные» . Переключите «Поля» со «Стандартные» на «Нет» . Связанные страницы Задание не распечатывается на принтере Медленная печать или долгая обработка документов

Проблемы печати

Медленная печать или долгая обработка документов

Симптом Большие документы долго обрабатываются системой, отправка задания на устройство занимает значительное время. Диагностика и решение Шаг 1. Переключить формат на PostScript (для печати без клиента ПМ) В панели администратора ПринтМенеджер: Системные настройки → Настройки печати → включить параметр USE_PS_PRINTING . Ограничения PostScript-режима: не применяется при правилах по количеству страниц/цветности и при автоудалении документа. На Konica Minolta и Kyocera может печататься дополнительная техническая страница. Шаг 2. Заменить драйвер в CUPS Если переключение на PostScript не помогло — замените драйвер Generic PostScript на родной драйвер модели или Generic PCL. Шаг 3. Проверить нагрузку на сервер Проверьте загрузку CPU и памяти на сервере ПринтМенеджер. В кластерной конфигурации — добавьте серверы ПринтМенеджер (1 сервер ≈ 100 заданий/мин). Связанные страницы Задание не распечатывается на принтере Управление драйверами и протоколами

Проблемы печати

Не печатаются схемы в PDF при отложенной печати

Симптом

PDF-документы со схемами или чертежами не печатаются или отображаются некорректно при отложенной печати без клиента ПМ.

Решения

Шаг 1. Попробовать другой браузер/приложение

Если печать идёт из Chrome или Yandex Browser — попробуйте Firefox. Разные приложения по-разному растеризуют PDF.

Шаг 2. Отключить пересылку PostScript в драйвере (Windows 10)

Пуск → Параметры → Устройства → Принтеры и сканеры.
Выберите принтер Printum → Управление → Настройки печати → вкладка «Дополнительно».
Откройте Драйвер (+) → Пересылка PostScript → Выключено → ОК.

Предупреждение: это может ухудшить качество печати других документов.

Шаг 3. Замена драйвера АРМ (Konica Minolta, Kyocera)

Если вместе с заданием печатается дополнительный технический лист — замените драйвер АРМ на HP Universal Printing PS:

Скачайте HP Universal Printing PS с сайта HP.
Удалите принтеры бесклиентской печати.
Переустановите, выбрав файл hpbuio200l.inf из архива.

Связанные страницы

Проблемы печати

Ошибка printer.py при обработке задания

Описание

Консольное приложение printer_scan.py используется для диагностики обнаружения устройств в сети — проверяет доступность принтеров и наличие SNMP. Это инструмент диагностики, а не компонент основного потока печати.

Симптомы

Скрипт printer_scan.py завершается с ошибкой или не выводит ожидаемых результатов.
Устройства не обнаруживаются при сканировании.

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

Не установлены зависимости: библиотеки nmap и pandas.
Файл Devices.xlsx отсутствует или назван некорректно.
Указан некорректный диапазон IP-адресов.
Файл printer_scan.py не был получен от службы технической поддержки.

Диагностика и решение

Убедитесь, что установлены необходимые библиотеки (nmap и pandas).
Убедитесь, что файл корректно перенесён на сервер и запускается из своей папки:
```
python3 printer_scan.py
```
Убедитесь, что файл Devices.xlsx (экспорт из ЛК → раздел «Устройства» → кнопка «Excel») переименован корректно и находится в доступном месте.
При запросе IP-адресов убедитесь в корректности диапазона (формат: подсеть или диапазон).
Если файл printer_scan.py отсутствует — запросите его у службы технической поддержки.

Что проверить перед эскалацией

Зависимости установлены.
Файл Devices.xlsx получен из ЛК текущей установки и переименован в Devices.xlsx.
Диапазон IP-адресов корректен и соответствует сети с принтерами.

Проблемы печати

Постоянный запрос токена на МФУ Ricoh

Симптомы Встроенное приложение на МФУ Ricoh постоянно запрашивает получение токена. Авторизация пользователей не завершается. Возможная причина Проблема может быть вызвана сторонними приложениями, установленными на принтере, которые взаимодействуют с устройством и конфликтуют с системой Принтум. Например, это могут быть утилиты управления, такие как Device Software Manager . Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — обработка запросов авторизации от встроенного приложения cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-converter-server — TCP-конвертер — приём запросов авторизации по TCP от устройства cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-converter-server Что искать в логах Выявить, приходит ли сообщение от конвертера. Выявить ошибки авторизации по TCP. Выявить ошибки обработки API-запросов от встроенного приложения МФУ. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Проверьте установленные приложения: Откройте интерфейс управления принтером. Войдите в систему под логином и паролем администратора. Перейдите в раздел, где перечислены все установленные приложения. Удалите сторонние приложения: Найдите приложения, не связанные с системой Принтум, но имеющие доступ к принтеру. Удалите их. Особое внимание уделите утилитам, которые могут управлять настройками устройства. Перезагрузите принтер: после внесённых изменений выполните перезагрузку устройства, чтобы убедиться в устранении проблемы. Что проверить перед эскалацией Все сторонние приложения удалены. Принтер перезагружен после удаления приложений. В обращении указана модель устройства и подробное описание ситуации.

Проблемы печати

Проблемы с печатью из Office 2010

Симптомы Цветные документы, распечатанные из Microsoft Office 2010 через Клиент ПМ, выходят в чёрно-белом виде. Возможная причина Особенность обработки цветовой модели в заданиях, формируемых Microsoft Office 2010. Требуется включение конвертации через Ghostscript и анализа цветности PDF. Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — приём и обработка заданий cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-cups — Сервер печати CUPS — обработка и отправка задания на принтер cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-cups printmanager-celery — Фоновые задачи ПринтМенеджер — обработка заданий печати cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-celery Что искать в логах Выявить ошибки при получении и обработке задания из Office 2010. Выявить ошибки работы сервиса CUPS. Выявить ошибки при печати заданий в фоновой очереди. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Перейдите в папку с установленным Клиентом ПМ: C:\Program Files\printum\printmanager_client Откройте файл settings.yml . Измените следующие строки: use_gs_conversion: true use_pdf_color_analysis: true Сохраните файл и перезапустите службу Printum Optimize Service (через компонент services ). Что проверить перед эскалацией Параметры use_gs_conversion и use_pdf_color_analysis установлены в true . Служба Printum Optimize Service перезапущена. Проверена печать цветного документа после изменений.

Проблемы печати

Проблемы с печатью из LibreOffice

Симптомы При отправке задания печати из LibreOffice через Клиент ПМ в очереди печати появляется дополнительная копия задания (задание отправляется дважды). Возможная причина LibreOffice по умолчанию отправляет задания в формате, при обработке которого Клиент ПМ получает дублирующую копию. Исправляется настройкой вывода заданий в формате PDF. Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — приём и обработка заданий cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-cups — Сервер печати CUPS — обработка и отправка задания на принтер cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-cups printmanager-celery — Фоновые задачи ПринтМенеджер — обработка заданий печати cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-celery Что искать в логах Выявить ошибки при получении и обработке задания из LibreOffice. Выявить ошибки работы сервиса CUPS. Выявить ошибки при печати заданий в фоновой очереди. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Откройте LibreOffice и перейдите в настройки ( Alt + F12 ). В разделе «LibreOffice» откройте подраздел «Печать» . Включите галочку «Задания печати в формате PDF» . Что проверить перед эскалацией Галочка «Задания печати в формате PDF» установлена в настройках LibreOffice. Проверена печать после изменения настройки.

Проблемы печати

Встала печать после обновления — Bad response from monitoring 500

title: Встала печать после обновления — Bad response from monitoring 500 slug: ts-bad-response-500-posle-obnovleniya tags: [обновление, bad response, 500, синхронизация, печать] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг, ПринтМенеджер] related_pages:

kak-obnovit-printum
kak-rabotaet-sinhronizaciya-monitoring-i-printmanager

Встала печать после обновления — Bad response from monitoring 500

Симптомы

После обновления М или ПринтМенеджер печать перестала работать на всех или части устройств.
В логах ПринтМенеджер или на почту администраторов приходят ошибки вида:
```
Bad response from monitoring 500
```
Синхронизация Мониторинг–ПринтМенеджер завершается с ошибкой.

Причина

После обновления М изменился адрес, порт или протокол синхронизации. ПринтМенеджер продолжает обращаться по старым параметрам — получает 500 вместо корректного ответа.

Диагностика

Проверить логи ПринтМенеджер:

cd /opt/printmanager
sudo docker-compose logs printum_worker-high --tail=100 | grep -i "bad response\|monitoring"

Проверить доступность М с сервера ПринтМенеджер:

curl -k https://<адрес_М>:8001/api/health/

Норма: ответ 200. Ошибка: connection refused, timeout, 500.

Решение

1. Проверить настройки синхронизации в ЛК

ЛК → Настройки → Интеграции → ПринтМенеджеры: убедиться, что адрес М и порт указаны корректно.

2. Проверить .env ПринтМенеджер

grep MONITORING_ADDRESS /opt/printmanager/.env

Адрес должен совпадать с актуальным адресом сервера М.

3. Перезапустить ПринтМенеджер

cd /opt/printmanager
sudo docker-compose down && sudo docker-compose up -d

4. Запустить синхронизацию вручную

В панели администратора М → ПринтМенеджеры → кнопка «Синхронизировать».

Как проверить результат

Синхронизация завершается без ошибок.
Задания уходят на МФУ.
Логи не содержат Bad response from monitoring.

Когда эскалировать

После всех шагов ошибка сохраняется.
Адрес М в .env корректный, но ответ всё равно 500.
М недоступен с сервера ПринтМенеджер — сетевая проблема.

Приложить к заявке: версии М и ПринтМенеджер, вывод docker-compose ps, логи printum_worker-high.

Связанные страницы

Проблемы печати

Пользователь авторизовался, но задания не отображаются

title: Пользователь авторизовался, но задания не отображаются slug: ts-zadaniya-ne-otobrazhaetsya-v-prilozhenii tags: [встроенное приложение, задания, очередь, синхронизация, лицензия, пользователь] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер, Мониторинг] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya
kak-diagnostirovat-problemy-pechati-po-etapam-puti-zadaniya

Пользователь авторизовался, но задания не отображаются

Симптомы

Авторизация на МФУ прошла успешно.
Экран очереди пуст — нет ни одного задания.
Задания были отправлены с АРМ, но до МФУ не дошли.

Диагностика

Шаг 1. Проверить, есть ли задание в очереди ПринтМенеджер

Панель администратора ПринтМенеджер → Задания → очередь. Задание должно быть там.

Если задания нет в ПринтМенеджер — проблема на стороне клиента ПМ или бесклиентского принтера. См. Как диагностировать проблемы печати.

Если задание есть в ПринтМенеджер, но не отображается на МФУ — идём дальше.

Шаг 2. Проверить, кому принадлежит задание

Задание должно принадлежать тому же пользователю, под которым выполнена авторизация. Пользователь на АРМ и пользователь в Printum должны совпадать.

Шаг 3. Проверить синхронизацию Мониторинг–ПринтМенеджер

Настройки пользователя (в том числе привязка карты, PIN-код) передаются из М в ПринтМенеджер при синхронизации. Если пользователь был добавлен или изменён недавно — синхронизация могла не выполниться.

Запустить синхронизацию вручную: панель администратора М → ПринтМенеджеры → «Синхронизировать».

Шаг 4. Проверить лицензии устройства

ЛК → Управление → Устройства → вкладка «Лицензии». Должны быть активны M, PM, EMB.

Шаг 5. Проверить правила печати

Если у пользователя есть правило «Запретить печать» или «Запретить авторизацию в приложении» — задания будут заблокированы.

ЛК → Управление → Пользователи → карточка пользователя → правила.

Решение

По результатам диагностики:

Нет задания в ПринтМенеджер → диагностировать путь задания от АРМ.
Задание принадлежит другому пользователю → проверить УЗ на АРМ и в Printum.
Не прошла синхронизация → запустить вручную.
Нет лицензии EMB → активировать.
Правило запрещает → изменить правило или проконсультировать заказчика.

Как проверить результат

Отправить тестовое задание от пользователя. Авторизоваться на МФУ — задание отображается и уходит на печать.

Когда эскалировать

Задание есть в ПринтМенеджер, принадлежит правильному пользователю, лицензии активны, правил нет — задание не отображается.
После синхронизации ситуация не изменилась.

Приложить к заявке: вендор, модель МФУ, версии М и ПринтМенеджер, логи printmanager-app, скриншот карточки задания в ПринтМенеджер.

Связанные страницы

Задание не распечатывается на принтере

Симптом Задание появилось в очереди Printum, пользователь авторизовался на МФУ, но документ не вышел на печать. Диагностика Шаг 1. Проверить статус задания в CUPS Откройте CUPS: https://<ip_сервера>:1631 Перейдите во вкладку «Задания» и найдите задание. Если задание отсутствует — проблема на стороне клиента ПринтМенеджер (см. «Задание не появляется в очереди»). Если статус отличается от «напечатано» (например, Broken pipe ) — проблема в подключении CUPS к принтеру. Шаг 2. Проверить протокол подключения в CUPS Перейдите во вкладку «Принтеры» в CUPS. Сравните адрес и метод подключения устройства (ipp, ipps, socket). Если метод отличается от поддерживаемого для вендора — измените протокол в карточке устройства в Printum (вкладка «Драйвер»). Шаг 3. Заменить драйвер в CUPS Если проблема не решена (медленная печать, некорректные символы, нечёткие изображения, не работает дуплекс): замените драйвер с Generic PostScript на родной драйвер модели или Generic PCL. Типовые ошибки | Ошибка | Причина | Решение | | --------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Job failed: Error 401 | Неверный логин/пароль CUPS или отключён ALLOW_BYPASS_PRINTING | Проверьте настройки сервера печати. Включите ALLOW_BYPASS_PRINTING в настройках печати ПринтМенеджер. | | Broken pipe | Разрыв соединения с принтером | Проверьте сетевую доступность принтера. Измените протокол подключения. | Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — обработка заданий, взаимодействие с принтерами cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-cups — Сервер печати CUPS — обработка и отправка заданий на принтер cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-cups printmanager-celery-print-queue — Очередь бесклиентской печати — проверка CUPS на наличие новых заданий cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-celery-print-queue Что искать в логах Выявить ошибки при отправке задания на принтер. Определить причины возврата кодов 4xx/5xx. Выявить ошибки работы сервиса CUPS и ошибки принтеров в CUPS. Выявить ошибки соединения с принтерами. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Связанные страницы Задание не появляется в очереди печати Управление драйверами и протоколами

Проблемы авторизации

Пользователь не может авторизоваться на МФУ по карте

Симптом

Пользователь прикладывает карту к считывателю, но авторизация не происходит или появляется сообщение об ошибке.

Диагностика

Шаг 1. Проверить наличие карты в системе

Перейдите в Управление → Пользователи, откройте карточку пользователя → вкладка «Авторизация». Убедитесь, что карта привязана к учётной записи.

Шаг 2. Проверить способы добавления карты

Самостоятельная привязка на МФУ (рекомендуется): встроенное приложение предложит привязку при первом прикладывании. Введите PIN-код и нажмите «Привязать».
Импорт из домена: убедитесь, что атрибут карты указан в настройках синхронизации с доменом.
Ручной ввод: администратор добавляет карту в карточке пользователя.
Импорт из файла: загрузка CSV/XLS через панель администратора Мониторинга → «Карты авторизации» → «Импорт».

Шаг 3. Проверить картридер

Убедитесь, что тип картридера соответствует стандарту карты (MIFARE, HID, EM-Marine и др.).
Проверьте физическое подключение картридера к МФУ.
Протестируйте другую карту того же стандарта.

Шаг 4. Проверить совместимость

Возможны нюансы в сочетаниях «картридер ↔ модель принтера». Проверьте рекомендованный список картридеров (по запросу в поддержку Printum).

Что проверить перед эскалацией

Карта привязана к пользователю в системе
Картридер физически работает
Тип карты поддерживается

Связанные страницы

Проблемы авторизации

Пользователь не может авторизоваться на МФУ по PIN

Симптом

Пользователь вводит PIN-код на экране МФУ, но авторизация не происходит или отображается ошибка.

Диагностика

Шаг 1. Убедиться, что PIN-код сгенерирован

Перейдите в Управление → Пользователи, откройте карточку пользователя → вкладка «Авторизация». PIN-код должен быть сгенерирован и отправлен на e-mail пользователя.

Шаг 2. Перегенерировать PIN-код

В карточке пользователя (вкладка «Авторизация») нажмите «Сгенерировать PIN-код».
Убедитесь, что e-mail пользователя указан и почтовый сервер настроен.
Попросите пользователя проверить почту и использовать новый PIN.

Шаг 3. Проверить настройку SMTP

Если PIN не доходит по почте — проверьте настройки SMTP (Настройки → Интеграции → Почта). Отправьте тестовое письмо.

Шаг 4. Проверить встроенное приложение

PIN-авторизация доступна только во встроенном приложении Printum на устройстве. Убедитесь, что встроенное приложение установлено и активировано (лицензия EMB).

Важно

Администратор не видит PIN-код в открытом виде — только инициирует генерацию.

Связанные страницы

Проблемы авторизации

Пользователь не может войти в Личный кабинет

Симптом

Пользователь не может войти в веб-интерфейс Printum (Личный кабинет) по логину/паролю или доменной учётной записи.

Диагностика

Шаг 1. Проверить тип авторизации

Логин/пароль Printum: убедитесь, что пользователь существует в системе и пароль задан. При необходимости — сбросьте пароль через «Восстановить пароль» на странице входа.
Доменная УЗ / SSO: убедитесь, что SSO настроен (SAML или Kerberos) и пользователь импортирован из домена.

Шаг 2. Восстановить пароль

На странице авторизации нажмите «Восстановить пароль».
Введите e-mail, привязанный к учётной записи, нажмите «Отправить код».
Введите код из письма, задайте новый пароль.

Шаг 3. Проверить почтовый сервер

Если письмо не приходит — проверьте настройки SMTP (Настройки → Интеграции → Почта).

Шаг 4. Проверить роль пользователя

Убедитесь, что пользователю назначена роль с правом доступа к ЛК. Роль «Пользователь» имеет минимальный доступ.

Связанные страницы

Проблемы авторизации

Авторизация по карте не работает во встроенном приложении

title: Авторизация по карте не работает во встроенном приложении slug: ts-avtorizaciya-po-karte-ne-rabotaet-v-prilozhenii tags: [авторизация, карта, считыватель, RFID, Elatec, VID, PID, встроенное приложение] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер, Мониторинг] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya
kak-rabotaet-rfid-avtorizaciya-v-printum

Авторизация по карте не работает во встроенном приложении

Симптомы

Считыватель реагирует на карту (мигает, пищит), но авторизация в приложении не происходит.
После прикладывания карты — экран остаётся на стартовом, сессия закрывается или появляется ошибка.
Предложения привязать карту не появляется.

Диагностика

Шаг 1. Убедиться, что считыватель виден МФУ

Войти в веб-интерфейс МФУ → раздел с USB-устройствами или внешними устройствами. Считыватель должен отображаться.

Для ряда вендоров (Pantum, Kyocera) в веб-интерфейсе нужно вручную указать VID и PID считывателя. Проверить, что они заданы корректно.

Шаг 2. Проверить тип карты и считывателя

Считыватель должен поддерживать тип карт заказчика (MIFARE, HID, EM-Marine и др.). Проверить совместимость: приложить карту к считывателю, подключённому к ПК — данные должны считываться.

Шаг 3. Проверить, привязана ли карта к пользователю

Панель администратора М → Пользователи → карточка пользователя → поле «Серийный номер карты».

Если поле пустое — карта не привязана. Варианты привязки:

Самостоятельно на МФУ через PIN-код (рекомендуется).
Вручную администратором в карточке пользователя.
Импорт из домена или файла.

Шаг 4. Проверить настройки авторизации в ПринтМенеджер

Панель администратора ПринтМенеджер → Настройки → Авторизация: карточная авторизация должна быть включена.

Частые ситуации

Считыватель не определяется МФУ

Попробовать другой USB-порт МФУ. Перезагрузить МФУ с подключённым считывателем. Если считыватель по-прежнему не определяется — возможна несовместимость считывателя и МФУ. Рекомендуется тест с рекомендованными считывателями (список — у ТП).

VID/PID указаны неверно (Pantum, Kyocera)

VID и PID считывателя можно найти:

В документации к считывателю.
На ПК: Диспетчер устройств → считыватель → Свойства → Сведения → ИД оборудования.

Карта считывается, но авторизация не происходит (Pantum)

Сообщение «не введён PIN-код» вместо авторизации по карте означает, что приложение не получило серийный номер карты. Проверить:

Считыватель подключён к правильному порту МФУ.
VID/PID в веб-интерфейсе МФУ указаны верно.
В настройках МФУ включена авторизация по картам.

После прикладывания карты сессия закрывается (Pantum)

Это происходит, если пользователь уже авторизован — повторное прикладывание карты завершает сессию. Нормальное поведение.

Как проверить результат

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

Когда эскалировать

VID/PID указаны верно, карта привязана, считыватель виден МФУ — авторизация не происходит.
Ни один считыватель из нескольких протестированных не работает с данной моделью МФУ.

Приложить к заявке: вендор и модель МФУ, марка и модель считывателя, тип карт, версии М и ПринтМенеджер, версия приложения, логи printmanager-converter-server.

Связанные страницы

Проблемы обнаружения устройств

Принтер не обнаружен при сетевом сканировании

Симптом

Принтер включён и доступен в сети, но не появляется в Printum после сканирования локации.

Диагностика

Шаг 1. Проверить настройки локации

Перейдите в Управление → Устройства → Локации. Убедитесь, что IP-адрес принтера входит в диапазон сканирования локации и не попадает в список исключений.

Шаг 2. Проверить SNMP на принтере

SNMP v1/v2 должен быть включён на принтере.
Проверьте, что community string совпадает с настройками сканирования.
Убедитесь, что порт UDP 161 открыт между сервером Мониторинга и принтером.

Шаг 3. Запустить сканирование вручную

После исправления настроек перезапустите сканирование сети в разделе Управление → Устройства → Локации.

Шаг 4. Проверить сетевую доступность

ping <ip_принтера>
# Проверка SNMP:
snmpwalk -v2c -c public <ip_принтера>

Что проверить перед эскалацией

IP принтера в диапазоне локации
SNMP включён на принтере
Нет firewall-блокировки UDP 161

Связанные страницы

Проблемы обнаружения устройств

Некорректно отображаются запчасти устройства

Симптом

На вкладке «Детали» устройства отображаются неверные данные о расходных материалах или запчастях (неверный процент, неверное название).

Диагностика

Шаг 1. Проверить тип показателя

Показатели из SNMP помечены иконкой принтера (столбец «Оставшийся ресурс»).
Расчётные показатели (по объёму печати) помечены иконкой базы.

Шаг 2. Проверить OID-параметры устройства

Откройте карточку устройства → вкладка «Параметры».
Нажмите кнопку SNMP для просмотра всех SNMP-данных устройства.
Сопоставьте OID значения с ожидаемыми параметрами и исправьте при необходимости.

Шаг 3. Проверить характеристики модели

Вкладка «Характеристики» — убедитесь, что тип устройства и параметры указаны корректно.

Связанные страницы

Проблемы обнаружения устройств

Некорректный счётчик отпечатков

Симптом

Счётчик отпечатков в системе не совпадает с реальным показателем на принтере или не обновляется.

Диагностика

Шаг 1. Проверить синхронизацию SNMP-данных

Откройте карточку устройства → вкладка «Параметры» → нажмите SNMP.
Убедитесь, что OID для счётчика отпечатков указан корректно (обычно prtMarkerLifeCount).

Шаг 2. Проверить периодичность опроса

Данные обновляются по расписанию SNMP-опроса. Проверьте журнал событий устройства (вкладка «Журнал») — когда последний раз обновлялись данные.

Шаг 3. Проверить лицензию мониторинга

Сбор SNMP-данных требует активной лицензии типа M. Убедитесь, что лицензия назначена устройству (вкладка «Лицензии»).

Связанные страницы

Проблемы обнаружения устройств

Не все устройства отображаются в системе

Симптомы

Часть принтеров и МФУ не появляется в списке устройств в Личном кабинете.
Устройства в сети существуют и доступны, но система их не обнаруживает.

Диагностика и решение

1. Проверьте настройки локации

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

Нужный IP-адрес указан в поле «IP-адреса устройств».
Нужный IP-адрес не указан в поле «Исключить IP-адреса».

2. Проверьте назначение агента мониторинга

Перейдите во вкладку «Настройки» → «Общие настройки» → «Модули» и выберите вариант «Сетевой агент». Локация с устройствами должна быть отмечена чек-боксом или входить в другую локацию, отмеченную чек-боксом.

3. Проверьте доступность принтера в сети

На ПК, находящемся в одной сети с принтером, откройте браузер и укажите в адресной строке IP-адрес принтера.

4. Проверьте SNMP на устройстве

Если принтер отвечает по IP-адресу — проверьте, включена ли передача данных по протоколу SNMP. Выполните команды:

snmpwalk -v 2c -c public printer-ip-address

или

snmpwalk -v 1 -c public printer-ip-address

Если принтеры не отвечают на команды — откорректируйте настройки принтеров и включите передачу данных по протоколу SNMP.

5. Проверьте ошибки идентификации

Если нужный IP-адрес указан в настройках локаций, принтер отвечает и SNMP включён, вероятно, потребуется настройка SNMP-параметров для данной модели. При обращении в техподдержку укажите ошибки идентификации: перейдите в «Инвентаризация» → «Устройства», найдите устройство по IP и скопируйте данные из столбца «Ошибки идентификации».

Массовая проверка через printer_scan.py

Для проверки большого количества устройств используется консольное приложение printer_scan.py. Файл запросите у службы технической поддержки.

Перед использованием установите библиотеки nmap и pandas.

Перенесите printer_scan.py на сервер в любое место.
Зайдите в Личный кабинет, в раздел «Устройства».
Выберите необходимую локацию и нажмите кнопку «Excel».
Полученный отчёт переименуйте в Devices.xlsx и перенесите на сервер.
Из папки с приложением введите команду:

python3 printer_scan.py

Приложение запросит IP-адреса — введите диапазоном или подсетью.
Программа выведет устройства в 4 группы:
- IPs that are up — общий список откликнувшихся адресов.
- Checked as printers — устройства, отмеченные как принтеры.
- Doubtful devices with no snmp — устройства с выключенным SNMP.
- Not printers — устройства, не являющиеся принтерами.
При запросе сравнения со списком из ЛК — введите y и укажите полный путь до файла Devices.xlsx.
Отчёты сохраняются в формате CSV:
- netscan_with_snmp.csv — принтеры с включённым SNMP.
- netscan_without_snmp.csv — принтеры с выключенным SNMP.
- not_found_in_monitoring.csv — не найденные в мониторинге.

Что проверить перед эскалацией

IP-адрес устройства входит в диапазон локации и не исключён.
Сетевой агент назначен на локацию с устройствами.
Устройство доступно по сети (браузер, ping).
SNMP включён на устройстве (snmpwalk возвращает данные).
В обращении в поддержку указаны: ошибки идентификации, модель устройства, IP.

Проблемы обнаружения устройств

Некорректный список запчастей устройства

Симптомы

Наименования деталей отображаются на английском языке.
Тип детали отображается как «Другое».
Отсутствует парт-номер.
Данные по оставшемуся ресурсу деталей не отображаются.

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

Данные по запчастям отсутствуют в справочнике.
Наименование модели в справочнике не совпадает с тем, как модель принтера указывается в SNMP-данных.

Диагностика и решение

Шаг 1. Проверьте наличие в справочнике

Откройте панель администратора мониторинга, перейдите в «Инвентаризация» → «Запчасти». В строку поиска введите модель принтера именно так, как она отображается в личном кабинете, нажмите «Найти».

Если данные по запчастям отсутствуют — отправьте запрос в службу технической поддержки с указанием точной модели устройства (именно так, как она отображается в личном кабинете). Сотрудник направит обновлённый справочник, который необходимо загрузить в панели администратора (раздел «Загрузка справочников»).

Шаг 2. Данные есть в справочнике, но не отображаются

Причина: наименование модели в справочнике не совпадает с тем, как модель указывается в SNMP-данных, получаемых от устройства.

Для устранения требуется настройка интерпретации SNMP-данных или корректировка справочников. Отправьте запрос в службу технической поддержки с точным наименованием модели (именно так, как она отображается в личном кабинете).

Шаг 3. Некорректное отображение отдельных деталей

Если часть деталей отображается корректно, а часть — на английском с типом «Другое»:

Определите деталь по значению в поле «парт-номер» или по наименованию (например, «Fuser»).
Если деталь с корректным русским наименованием уже есть в списке, но дублируется — настройте синонимы, как описано в разделе «Настройка синонимов», скопировав значение из поля «Наименование» в поле «Синонимы».
Если подходящей детали с корректным наименованием нет — отправьте запрос в службу технической поддержки с точным указанием модели, детали и содержанием столбца «Наименование» в личном кабинете.

Шаг 4. Нет данных по оставшемуся ресурсу расходных материалов

Вероятнее всего, у принтера есть альтернативные запчасти и данные отображаются в строке другой детали. В этом случае следует объединить детали (раздел «Объединение деталей»).
Если альтернативные детали отсутствуют или корректно настроены, но данные всё равно не отображаются — настройте интерпретацию SNMP-данных для данной модели через раздел «Конфигурация» → «Параметры запчастей».

Что проверить перед эскалацией

Модель устройства в запросе указана точно так, как отображается в ЛК.
Проверены синонимы для дублирующихся деталей.
Проверено объединение деталей для альтернативных расходников.

Проблемы обнаружения устройств

Несколько расходных материалов одного цвета в списке запчастей

Симптомы

В списке запчастей одновременно отображаются несколько расходных материалов одного цвета, но разной ёмкости (например, два чёрных картриджа).

Диагностика и решение

Шаг 1. Определите установленный картридж

Проверьте, есть ли у одной из деталей в столбце «Оставшийся ресурс» иконка «принтер». Если да — именно эта деталь установлена в принтере. Чтобы скрыть остальные — объедините детали, как описано в разделе «Объединение деталей».

Шаг 2. Если иконки принтера нет ни у одной детали

Проверьте, есть ли в списке запчасти с английским наименованием и типом «Другое». Если есть и по наименованию можно определить, что это один из расходных материалов (например, наименование может быть: Black Toner HP CF256A) — настройте синонимы для детали, как описано в разделе «Настройка синонимов».

Шаг 3. Если предыдущие шаги не помогли

Отправьте запрос в службу технической поддержки через раздел «Обращение в техническую поддержку».

Что проверить перед эскалацией

Выполнены шаги 1 и 2.
В обращении указана модель устройства и содержимое столбца «Наименование» для каждой из дублирующихся деталей.

Проблемы обнаружения устройств

Статистика HP и Xerox отображается некорректно

Симптомы

При использовании МФУ HP с драйвером Xerox Global Print Driver PostScript статистика печати в Личном кабинете не соответствует реальному количеству листов, страниц и применению дуплекса.

Возможная причина

При использовании драйвера Xerox Global Print Driver PostScript для МФУ HP статистика печати передаётся некорректно. Необходимо настроить подключение принтера по протоколу IPP.

Логи и диагностические данные

Где смотреть логи

printum_worker-default — Воркер мониторинга — фоновая обработка данных от принтеров, обновление статистики
cd /opt/printum && docker-compose logs -f --tail=200 printum_worker-default
printum_worker-high — Воркер мониторинга (высокий приоритет) — срочные фоновые задачи
cd /opt/printum && docker-compose logs -f --tail=200 printum_worker-high
printum_worker-low — Воркер мониторинга (низкий приоритет) — фоновые задачи низкого приоритета
cd /opt/printum && docker-compose logs -f --tail=200 printum_worker-low
printum_backend — API мониторинга — обработка запросов на отображение статистики
cd /opt/printum && docker-compose logs -f --tail=200 printum_backend

Что искать в логах

Выявить ошибки обработки данных от принтеров HP/Xerox.
Выявить время запуска и завершения задач обновления статистики.
Выявить наличие ошибок по периодическим задачам сбора данных.
Определить причины возврата кодов 4xx/5xx при запросах статистики.

Что приложить к обращению в поддержку

Вывод команды bash /opt/printum/logs.sh
Версию: cat /opt/printum/.version
Описание сценария и шагов воспроизведения
ОС сервера

Решение

Войдите в Личный кабинет на страницу «Управление → Устройства → Все».
Найдите нужный принтер в таблице и откройте карточку принтера.
Перейдите во вкладку «Драйвер».
В поле «Протокол» выберите «ipp». Нажмите кнопку «Сохранить».
После синхронизации Мониторинга и ПринтМенеджера изменения вступят в силу.

Что проверить перед эскалацией

Протокол изменён на ipp в карточке устройства.
Выполнена синхронизация Мониторинга и ПринтМенеджера.
Статистика проверена после следующего задания печати.

Проблемы обнаружения устройств

Локальные принтеры не отображаются в статистике

Симптомы

Локальные принтеры меняют своё название после печати документов. В статистике Мониторинга отображаются некорректные имена устройств.

Возможная причина

Проблема связана с неактуальными заданиями печати в спулере АРМ, на котором работает локальный агент мониторинга.

Логи и диагностические данные

Где смотреть логи

Локальный агент Windows — Мониторинг заданий печати на ОС Windows
Откройте eventvwr → Журналы Windows → Приложение → источник ServicePrintum
Локальный агент Linux — Мониторинг заданий печати на ОС Linux
sudo journalctl -u printum-jtm.service

Что искать в логах

Выявить ошибки запуска сервиса локального агента.
Выявить ошибки передачи данных о локальных заданиях печати.

Что приложить к обращению в поддержку

Логи локального агента: Windows — Просмотр событий (eventvwr) → источник ServicePrintum; Linux — sudo journalctl -u printum-jtm.service
Описание сценария и шагов воспроизведения
ОС сервера и рабочей станции

Решение

Откройте командную строку с правами администратора и перейдите в директорию:

C:\Windows\System32\spool\PRINTERS

Остановите службу диспетчера печати:

net stop spooler

Удалите все файлы в директории:

del *.shd
del *.spl

Запустите службу диспетчера печати:

net start spooler

Что проверить перед эскалацией

Команды выполнены с правами администратора.
Служба диспетчера печати успешно перезапущена.
Имена принтеров стабилизировались после следующих заданий печати.

Проблемы обнаружения устройств

Сканирование — диагностика проблем

title: Сканирование — диагностика проблем slug: kak-diagnostirovat-problemy-skanirovaniya tags: [сканирование, email, SMB, папка, диагностика, встроенное приложение] domain: Troubleshooting type: Runbook audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

ts-skanirovanie-ne-priходит-na-email
ts-skanirovanie-ne-sohranyaetsya-v-papku
ts-skanirovanie-bolshoy-fayл
ts-kyocera-konica-skanirovanie-bolshih-faylov

Сканирование — диагностика проблем

Как работает сканирование в Printum

МФУ сканирует документ → встроенное приложение передаёт файл на сервер ПринтМенеджер → ПринтМенеджер отправляет файл на email или в сетевую папку пользователя.

Из этого следует: если скан не дошёл — проблема либо в передаче файла с МФУ на ПринтМенеджер, либо в отправке с ПринтМенеджер на email/SMB.

Предусловия для работы сканирования

Перед диагностикой убедиться:

Для сканирования на email:

Почтовый сервер настроен в ПринтМенеджер: панель администратора ПринтМенеджер → Настройки → SMTP. Тестовое письмо отправляется успешно.
У пользователя заполнен email в карточке.
Синхронизация Мониторинг–ПринтМенеджер выполнена.

Для сканирования в папку (SMB):

Настроены SMB_HOSTNAME, SMB_USERNAME, SMB_PASSWORD в панели ПринтМенеджер → Настройки → Настройки сканирования.
У пользователя или отдела заполнен путь к сетевой папке.
Пользователь SMB_USERNAME имеет права на запись в папку.

Алгоритм диагностики

Шаг 1. Проверить настройки ПринтМенеджер

Панель администратора ПринтМенеджер → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования».

Для email: проверить SMTP-настройки, отправить тестовое письмо. Для SMB: проверить SMB_HOSTNAME, SMB_USERNAME, SMB_PASSWORD.

Шаг 2. Проверить карточку пользователя

Панель администратора М → Пользователи → карточка пользователя:

Email заполнен и корректен.
Путь к сетевой папке заполнен (для SMB).

Шаг 3. Проверить, не запрещено ли сканирование правилом

ЛК → Управление → Пользователи → правила пользователя. Правило «Запретить сканирование в почту» или «Запретить сканирование в папку» блокирует функцию.

Шаг 4. Проверить логи ПринтМенеджер

cd /opt/printmanager
sudo docker-compose logs printmanager-app --tail=100 | grep -i "scan\|smtp\|smb\|error"

Шаг 5. Проверить, дошёл ли файл до ПринтМенеджер

В панели администратора ПринтМенеджер → Задания: задание сканирования должно появиться после выполнения операции на МФУ.

Если задания нет — файл не был передан с МФУ на ПринтМенеджер. Проверить сетевой доступ МФУ к серверу ПринтМенеджер и версию прошивки встроенного приложения.

Навигация по конкретным проблемам

Симптом	Статья
Скан не приходит на email	Скан не приходит на email
Скан не сохраняется в сетевую папку	Скан не сохраняется в сетевую папку
Большой файл не доходит по email	Большой файл сканирования не доходит
Konica Minolta / Kyocera: сканирование зависает при высоком DPI	Konica Minolta / Kyocera — сканирование больших файлов
Ricoh: скан не отправляется после таймаута сессии	Ricoh — скан не отправляется после таймаута сессии

Что приложить при эскалации в ТП

Вендор и модель МФУ, версия приложения.
Тип сканирования: email или SMB.
Версии М и ПринтМенеджер.
Логи printmanager-app.
Описание: задание появляется в ПринтМенеджер или нет.

Проблемы обнаружения устройств

Konica Minolta / Kyocera — сканирование зависает при высоком DPI

title: Konica Minolta / Kyocera — сканирование зависает при высоком DPI slug: ts-kyocera-konica-skanirovanie-bolshih-faylov tags: [сканирование, Konica Minolta, Kyocera, DPI, FTP, KONICA_TRANSFER_PROTOCOL] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-skanirovaniya
ts-skanirovanie-bolshoy-fayl

Konica Minolta / Kyocera — сканирование зависает при высоком DPI

Симптомы

На МФУ Konica Minolta или Kyocera при сканировании документов с высоким разрешением (DPI ≥ 600) или многостраничных документов:

Сканирование зависает или занимает очень долго.
Файл не доходит до ПринтМенеджер.
При малом DPI (150-300) сканирование работает нормально.

Причина

На некоторых моделях Konica Minolta и Kyocera при передаче больших файлов по умолчанию используется протокол, который плохо справляется с объёмными данными. Смена протокола передачи на FTP решает проблему.

Решение

Панель администратора ПринтМенеджер → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройка приложения для принтеров KONICA MINOLTA» → переменная KONICA_TRANSFER_PROTOCOL.

Изменить значение на FTP → сохранить.

Как проверить результат

Отсканировать документ с DPI 600 на Konica Minolta или Kyocera. Файл передаётся на ПринтМенеджер без зависания и доходит до email или папки пользователя.

Когда эскалировать

Смена протокола на FTP не помогла.
Зависание происходит и при малом DPI.
Проблема только на одной конкретной модели.

Приложить: вендор и модель МФУ, версия прошивки, значение KONICA_TRANSFER_PROTOCOL, DPI при котором воспроизводится, логи printmanager-app.

Связанные страницы

Проблемы обнаружения устройств

Ricoh — приложение постоянно запрашивает токен

title: Ricoh — приложение постоянно запрашивает токен slug: ts-ricoh-postoyannyy-zapros-tokena tags: [Ricoh, токен, встроенное приложение, Device Software Manager, конфликт] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya

Ricoh — приложение постоянно запрашивает токен

Симптомы

На МФУ Ricoh встроенное приложение Printum при каждом открытии запрашивает ввод токена, несмотря на то что токен уже был введён ранее и приложение работало.

Причина

Стороннее приложение, установленное на МФУ, конфликтует с приложением Printum и сбрасывает его настройки. Наиболее часто виновник — Device Software Manager или другие утилиты управления устройством от производителя или третьих сторон.

Решение

Открыть веб-интерфейс МФУ Ricoh → войти под учётной записью администратора.
Перейти в раздел установленных приложений.
Найти и удалить все сторонние приложения, не связанные с Printum (особое внимание: Device Software Manager и аналогичные утилиты управления).
Перезагрузить МФУ.
Открыть приложение Printum — токен запрашиваться не должен.

Как проверить результат

Приложение открывается без запроса токена. Авторизация по карте или PIN-коду работает в штатном режиме.

Когда эскалировать

Сторонних приложений нет, но токен запрашивается каждый раз.
После удаления стороннего ПО проблема сохраняется.

Приложить к заявке: модель МФУ Ricoh, версия прошивки, версия приложения Printum, список установленных приложений на МФУ.

Связанные страницы

Встроенное приложение — диагностика проблем

Проблемы обнаружения устройств

Ricoh — скан не отправляется после таймаута сессии

title: Ricoh — скан не отправляется после таймаута сессии slug: ts-ricoh-skan-posle-taymaut-sessii tags: [сканирование, Ricoh, таймаут, сессия, большой документ, email] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-skanirovaniya

Ricoh — скан не отправляется после таймаута сессии

Симптомы

На МФУ Ricoh при сканировании документов объёмом 50+ страниц:

Сканирование занимает более 60 секунд.
По истечении таймаута сессия пользователя завершается автоматически.
После окончания сканирования письмо на email не приходит.
Задание сканирования в ПринтМенеджер не появляется.
При ручном продлении сессии или увеличении таймаута — скан доходит.

Причина

Приложение завершает обработку сканирования вместе с сессией пользователя. Если сканирование занимает больше времени, чем таймаут сессии МФУ (по умолчанию 60 секунд), документ теряется.

Решение

Вариант 1. Увеличить таймаут сессии на МФУ

В веб-интерфейсе МФУ Ricoh → Настройки → таймаут сессии (Session Timeout / Auto Logout Timer). Установить значение выше времени сканирования документа (например, 180-300 секунд).

Это самый простой и быстрый вариант.

Вариант 2. Уменьшить DPI или количество страниц за один сеанс

Снизить разрешение сканирования (например, с 600 до 300 DPI) или разбить большой документ на несколько меньших.

Вариант 3. Использовать сканирование в папку вместо email

Сканирование в SMB-папку часто работает надёжнее для больших документов, так как не зависит от ограничений почтового сервера.

Как проверить результат

Отсканировать документ 50+ страниц при увеличенном таймауте. Задание появляется в ПринтМенеджер. Пользователь получает скан на email или в папку.

Когда эскалировать

Таймаут увеличен, но скан по-прежнему не приходит.
Задания нет в ПринтМенеджер даже при коротких документах.

Приложить: модель Ricoh, версия прошивки и приложения, текущее значение таймаута сессии, размер документа при котором воспроизводится, логи printmanager-app.

Связанные страницы

Проблемы обнаружения устройств

Большой файл сканирования не доходит по email

title: Большой файл сканирования не доходит по email slug: ts-skanirovanie-bolshoy-fayl tags: [сканирование, большой файл, email, SCAN_LARGE_DOC, разбиение, ссылка] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-skanirovaniya
ts-skanirovanie-ne-prikhodit-na-email

Большой файл сканирования не доходит по email

Симптомы

Сканирование небольших документов работает корректно.
При сканировании многостраничных документов или с высоким DPI (300+) письмо не приходит или приходит пустое.
Почтовый сервер отклоняет письмо из-за превышения размера вложения.

Причина

Почтовые серверы имеют ограничение на размер вложения (типично 10-25 МБ). Большие сканы превышают этот лимит и отклоняются SMTP-сервером.

Решение

Настроить способ обработки больших файлов в ПринтМенеджер:

Панель администратора ПринтМенеджер → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования» → переменная SCAN_LARGE_DOC_PROCESS_METHOD.

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

Значение	Поведение
Отправить ссылку для скачивания	Файл хранится на сервере ПринтМенеджер, пользователю приходит временная ссылка (по умолчанию 2 часа)
Отправить в сетевую папку	Файл автоматически перенаправляется в SMB-папку пользователя
Разделить по страницам	Документ разбивается на части, каждая часть — отдельное письмо
Разделить на zip-файлы	Документ разбивается на zip-архивы заданного размера

Настройка максимального размера (для разбиения):

Переменная SCAN_MAX_SIZE — максимальный размер одного сообщения в МБ. Рекомендуется устанавливать на 20-25% меньше лимита SMTP-сервера (например, если лимит 25 МБ — ставить 18-20 МБ).

Настройка срока действия ссылки (для варианта со ссылкой):

Переменная DOC_LINK_LIFETIME — срок в минутах (по умолчанию 120).

Как проверить результат

Отсканировать многостраничный документ (20+ страниц, 300 DPI). Пользователь получает письмо со ссылкой, несколькими частями или уведомлением о сохранении в папку — в зависимости от выбранного метода.

Когда эскалировать

Метод настроен, но большие файлы по-прежнему не доходят.
Ссылка для скачивания не открывается или сразу истекает.

Приложить: настройку SCAN_LARGE_DOC_PROCESS_METHOD, значение SCAN_MAX_SIZE, лимит SMTP-сервера, логи printmanager-app.

Связанные страницы

Проблемы обнаружения устройств

Встроенное приложение не устанавливается

title: Встроенное приложение не устанавливается slug: ts-vstroennoe-prilozhenie-ne-ustanavlivaetsya tags: [встроенное приложение, установка, App install failed, PEDK, токен, Pantum, Lexmark, Kyocera] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер, Мониторинг] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya

Встроенное приложение не устанавливается

Симптомы

Кнопка «Установить приложение» в ЛК не переключается на «Удалить приложение» — установка не завершается.
При ручной установке через PEDK или интерфейс МФУ: ошибка App installed failed, please try again later.
Токен сгенерирован, но при вводе на МФУ приложение не появляется.

Причины и решения

МФУ недоступен с сервера ПринтМенеджер

Автоматическая установка требует сетевого доступа от ПринтМенеджер к МФУ.

Проверить:

ping <ip_мфу>

Если МФУ недоступен — сетевая проблема на стороне заказчика.

Лицензия EMB не активирована или слоты исчерпаны

Проверить: ЛК → Управление → Устройства → карточка устройства → вкладка «Лицензии».

Лицензия EMB должна быть активна. Если слоты исчерпаны — освободить слот у другого устройства.

Важно: для EMB обязательно нужны активные лицензии M и PM на том же устройстве.

Несовместимая версия прошивки МФУ

Каждая версия встроенного приложения имеет требования к версии прошивки МФУ. Несовместимая прошивка — одна из наиболее частых причин ошибки App installed failed.

Проверить: запросить у ТП список совместимых прошивок для конкретной модели. Обновить прошивку МФУ при необходимости.

Для Pantum: прошивка TE13 совместима с текущей версией приложения (проверить актуальность в ТП).

Для Kyocera / Lexmark / Pantum: ошибка при установке через PEDK

Если используется PEDK-инсталлятор:

Убедиться, что версия PEDK актуальная (запросить у ТП).
Убедиться, что на МФУ нет ранее установленного приложения — удалить через веб-интерфейс МФУ.
Перезагрузить МФУ перед установкой.
Проверить правильность учётных данных администратора МФУ (логин/пароль).

Токен просрочен или использован

Токен — одноразовый. Если установка не завершилась, а токен уже был введён на МФУ:

В ЛК → «Удалить токен».
Сгенерировать новый токен.
Повторить установку.

Как проверить результат

ЛК → Управление → Устройства → карточка устройства: кнопка изменилась на «Удалить приложение». Приложение отображается на экране МФУ после перезагрузки.

Когда эскалировать

Прошивка совместимая, лицензии есть, МФУ доступен — но установка не проходит.
Ошибка воспроизводится на всех устройствах одной модели.
Нет совместимой прошивки для модели МФУ.

Приложить к заявке: вендор, модель, версия прошивки, версия приложения (если известна), версии М и ПринтМенеджер, логи printmanager-app.

Связанные страницы

Встроенное приложение — диагностика проблем

Проблемы обнаружения устройств

Xerox — сканирование или копирование не работает, ошибок нет

title: Xerox — сканирование или копирование не работает, ошибок нет slug: ts-xerox-skanirovanie-ne-rabotaet-bez-oshibok tags: [Xerox, AltaLink, сканирование, копирование, SenderPermissionDenied, автоопределение формата] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya

Xerox — сканирование или копирование не работает, ошибок нет

Симптомы

На МФУ Xerox AltaLink при сканировании или копировании через встроенное приложение Printum операция не выполняется. Ошибок на экране нет или появляется ошибка SenderPermissionDeniedClient … GetJobDetails.

Причина 1: Автоопределение формата не может определить размер оригинала

Если выбран режим «Автоопределение» формата оригинала, но МФУ не может его определить (стекло пустое, нестандартный размер, АПД неисправен) — операция зависает без явной ошибки.

Диагностика: во время сканирования на экране появляется таблица статусов. Если в конце InputScanSizeNotDetermined — причина в автоопределении.

Решение: выбрать формат оригинала вручную (A4, A3 и т.д.) вместо «Автоопределение».

Причина 2: Приложение «Работы» (Jobs) лишено прав

Приложение Printum использует системное приложение «Работы» (Jobs) на Xerox AltaLink для получения информации о статусе сканирования. Если это приложение было ограничено в правах — сканирование не фиксируется.

Ошибка: SenderPermissionDeniedClient … GetJobDetails

Решение: восстановить права приложения «Работы» в веб-интерфейсе МФУ. Инструкция производителя: https://www.support.xerox.com/en-us/article/en/2121276 (доступ с VPN).

Если ограничения не настраивались вручную — проверить настройку экрана блокировки (Lock Screen) в разделе настроек безопасности МФУ. Установить режим Custom и убедиться, что приложение «Работы» не заблокировано.

Как проверить результат

Запустить сканирование в тестовом режиме с явно указанным форматом A4. Документ сканируется и отправляется по назначению (email или папка).

Когда эскалировать

Формат указан вручную, права приложения восстановлены — сканирование не работает.
Проблема только на одной модели Xerox при одинаковых настройках.

Приложить к заявке: модель Xerox, версия прошивки, версия приложения, версии М и ПринтМенеджер, логи printmanager-app.

Связанные страницы

Встроенное приложение — диагностика проблем

Шаг 3 — Карта системы и где искать проблему

Ключевая мысль Проблема всегда находится в конкретном звене цепочки. После локализации и заполнения паспорта инцидента — определите цепочку компонентов для своего сценария, выберите предполагаемое звено и смотрите соответствующие логи. Тимур Гусев: «Если инженер умеет читать поток данных, он сможет понять, где именно у нас в этом месте в потоке данных сломалась передача». Пример 1: Задание не печатается | Элемент | Описание | | ------------------- | ----------------------------------------------------------------------------------------------------------- | | Сценарий | Прямая или отложенная печать с клиентом ПринтМенеджер | | Цепочка компонентов | АРМ → Клиент ПМ → Nginx (порт 8080) → Django (printmanager-app) → CUPS (printmanager-cups) → МФУ (порт 631) | | Где искать | Проверьте: дошло ли задание до сервера ПринтМенеджер; принял ли его CUPS; передал ли CUPS на МФУ | | Какие логи | printmanager-app , printmanager-cups , printmanager-celery-print-queue | Типичные ошибки: CUPS: Unable to send job to printer , CUPS: Unable to write print data: Broken pipe Пример 2: Нет данных по принтеру (не отображается в системе) | Элемент | Описание | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Сценарий | Мониторинг — устройство не появляется в личном кабинете | | Цепочка компонентов | МФУ → Сетевой агент (SNMP, порты 161/162) → Nginx → Django → ClickHouse → Celery (printum_worker) → PostgreSQL → Личный кабинет | | Где искать | 1) Устройство отвечает по SNMP? (snmpwalk) 2) Агент передал данные на сервер? 3) Данные попали в ClickHouse? 4) Celery обработал и записал в PostgreSQL? | | Какие логи | agent.log (/opt/printum-agent/agent.log), printum_worker-default , printum_worker-low | Типичные ошибки: ERROR [apps.inv.services.sync]: Some snmp data missing for printer 1 , Failed to connect to clickhouse:9000 Пример 3: Пользователь не авторизуется | Элемент | Описание | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Сценарий | Авторизация на МФУ по карте или PIN через встроенное приложение | | Цепочка компонентов (карта) | Карта → Конвертер (устройство) → Конвертер-сервер (printmanager-converter-server) → Django (printmanager-app) → PostgreSQL (поиск пользователя) | | Цепочка компонентов (PIN / внешняя) | МФУ → Встроенное приложение → Nginx → Django (printmanager-app) → PostgreSQL | | Где искать | Пользователь существует в системе? Карта сопоставлена? Данные синхронизированы из домена? | | Какие логи | printmanager-app , printmanager-converter-server | Типичные ошибки: AUTH_ERROR: Invalid credentials , User matching query does not exist Как читать цепочку Каждая стрелочка — это передача данных. Если пользователь не видит результат, значит разрыв произошёл где-то в цепочке. Метод диагностики: двигайтесь по цепочке от конца к началу (или от начала к концу) и проверяйте каждое звено по его логам. Связанные страницы Шаг 2 — Определение сценария и условий Шаг 4 — Сбор и чтение логов

Проблемы установки

Ошибки при установке Мониторинга

Типовые ошибки и решения

Ошибка: «E: Невозможно исправить ошибки: У вас зафиксированы сломанные пакеты»

Причина: прерывание установки пакетов (например, выключение сервера во время установки).

Решение: обратитесь к документации ОС. Если не помогло — удалите и переустановите пакеты вручную.

Ошибка: «Timeout error. Check docker logs. Then restart the installation.»

Причина: неверно указана переменная MON_HOSTNAME.

Решение: проверьте корректность IP-адреса или доменного имени. Запустите установку повторно с верными значениями.

Конфликт адресов Docker (разрыв SSH после установки)

Причина: внутренняя сеть Docker (10.28.32.0/26) пересекается с адресным пространством инфраструктуры.

Решение: выделите другой пул адресов для Docker. Подробнее — см. страницу «Конфликт адресов Docker при установке».

Логи и диагностические данные

Где смотреть логи

printum_nginx — HTTP-сервер и обратный прокси — первый контейнер, запускаемый при старте
cd /opt/printum && docker-compose logs -f --tail=200 printum_nginx
printum_backend — API мониторинга — основной контейнер приложения
cd /opt/printum && docker-compose logs -f --tail=200 printum_backend

Что искать в логах

Выявить ошибки запуска контейнеров при установке.
Выявить коды ошибок при инициализации приложения.
Определить, на каком этапе запуска происходит сбой.

Что приложить к обращению в поддержку

Вывод команды bash /opt/printum/logs.sh
Версию: cat /opt/printum/.version
Описание сценария и шагов воспроизведения
ОС сервера

Диагностика через Docker logs

cd /opt/printum
sudo docker-compose logs --tail=100

Связанные страницы

Проблемы установки

Ошибки при установке ПринтМенеджера

Типовые ошибки и решения Установка завершается с ошибкой при включённом шифровании Причина: не указана переменная ENV_VAULT_PASSWORD . Решение: sudo ENV_VAULT_PASSWORD= -E ./install.sh ПринтМенеджер не подключается к Мониторингу после установки Проверьте: Адрес Мониторинга доступен с сервера ПринтМенеджер. Порты 8000, 8001 открыты в firewall. Сертификаты сервера актуальны. Диагностика cd /opt/printmanager sudo docker-compose logs --tail=100 sudo docker-compose ps Логи и диагностические данные Где смотреть логи printmanager_web — Nginx ПринтМенеджера — первый контейнер, запускаемый при старте cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager_web printmanager-app — Основной контейнер ПринтМенеджер — проверка подключения к Мониторингу при старте cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app Что искать в логах Выявить ошибки запуска контейнеров при установке. Выявить ошибки подключения к Мониторингу. Определить, на каком этапе запуска происходит сбой. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Связанные страницы Ошибки при установке Мониторинга Конфликт адресов Docker при установке

Проблемы установки

Ошибки при установке Клиента ПМ на Windows

Симптом

При установке клиента ПринтМенеджер на Windows появляется предупреждение о сертификате или установка завершается с ошибкой.

Ошибка: предупреждение о сертификате драйвера

Диагностика

Запустите оснастку certlm.msc.
Проверьте раздел «Доверенные издатели» — должен присутствовать сертификат «ООО Принтум».
Нажмите ПКМ на сертификате → Открыть → Путь сертификации. Цепочка должна состоять из 3 ступеней. Сертификаты с ошибкой помечены жёлтым/красным.

Решение

GlobalSign GCC R45 EV CodeSigning CA 2020 → установить в Промежуточные центры сертификации.
GlobalSign Code Signing Root R45 → установить в Доверенные корневые центры сертификации.

Ошибка при пробной печати: «Невозможно завершить операцию (ошибка 0x00000077)»

Причина: проблема обновления Windows 10/11. Решение вне системы Printum — обратитесь к системному администратору.

Логи и диагностические данные

Где смотреть логи

Клиент ПМ Windows — Установка и запуск службы на ОС Windows
Логи установки: C:\Program Files\printum\service_install_*.log, driver_install_*.log
Логи работы службы: eventvwr → Журналы Windows → Приложение → источник Print Manager Client

Что искать в логах

Выявить ошибки запуска службы клиента ПМ после установки.
Выявить ошибки установки драйвера.

Что приложить к обращению в поддержку

Логи клиента ПМ: Windows — Просмотр событий (eventvwr) → Журналы Windows → Приложение → источник Print Manager Client; Linux — sudo journalctl -u printum-printmanager-client.service
Версию ПринтМенеджера: cat /opt/printmanager/.version
Описание сценария и шагов воспроизведения
ОС рабочей станции и сервера

Связанные страницы

Проблемы установки

Конфликт адресов Docker при установке

Симптомы После установки системы Принтум происходит разрыв соединения с сервером. Подключение по SSH становится недоступным сразу после установки или при первом запуске контейнеров. Возможные причины Конфликт IP-адресов между внутренней сетью Docker и реальной локальной сетью. Для работы Принтум используется внутренняя сеть Docker с пулом адресов: 10.28.32.0/26 Если данный диапазон пересекается с адресным пространством инфраструктуры — необходимо выделить другой пул адресов для Docker. Когда может возникнуть проблема Во время установки системы. Сразу после установки. При первом запуске контейнеров. Диагностика Если подключение по SSH недоступно — подключитесь к серверу через консоль гипервизора (vSphere / Proxmox / Hyper-V и т.д.). Логи и диагностические данные Где смотреть логи printum_nginx — Nginx Мониторинга — если конфликт возник при установке Мониторинга cd /opt/printum && docker-compose logs -f --tail=200 printum_nginx printmanager_web — Nginx ПринтМенеджера — если конфликт возник при установке ПринтМенеджер cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager_web Что искать в логах Выявить ошибки запуска контейнеров после изменения пула адресов. Проверить, что контейнеры успешно запустились после перенастройки сети Docker. Что приложить к обращению в поддержку Вывод команды bash /opt/printum/logs.sh (Мониторинг) или bash /opt/printmanager/logs.sh (ПринтМенеджер) Версию: cat /opt/printum/.version или cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Остановите контейнеры Принтум Если установлен Мониторинг: cd /opt/printum docker-compose down Если установлен ПринтМенеджер: cd /opt/printmanager docker-compose down Проверьте наличие файла конфигурации Docker Проверьте, существует ли файл /etc/docker/daemon.json . Если файла нет — создайте его: sudo nano /etc/docker/daemon.json Укажите новый пул IP-адресов Docker Добавьте или отредактируйте содержимое файла: { "default-address-pools": [ { "base": "x.x.x.x/x", "size": 26 } ] } "base" — выделенный диапазон IP-адресов, который не пересекается с локальной сетью. "size": 26 — размер подсети (изменять не требуется). Используйте только свободный диапазон, согласованный с сетевым администратором. Сохраните файл и выйдите из редактора. Перезапустите службу Docker sudo systemctl restart docker Запустите контейнеры Принтум Если установлен Мониторинг: cd /opt/printum docker-compose up -d Если установлен ПринтМенеджер: cd /opt/printmanager docker-compose up -d Проверьте адреса контейнеров sudo docker ps -q | sudo xargs -n 1 docker inspect -f '{{ .Name }}: {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' Ошибка при запуске контейнеров ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network Причина: выбранный диапазон адресов также пересекается с существующими сетями. Решение: вернитесь к шагу 3 и укажите другой диапазон IP-адресов. Если конфликт известен до установки Если известно, что адресное пространство 10.28.32.0/26 конфликтует с вашей сетью до установки системы — выполните инструкцию, игнорируя шаги 1 и 5 (остановку и повторный запуск контейнеров). Настройка пула выполняется до первого запуска системы. Что проверить перед эскалацией Выбранный диапазон не пересекается с другими подсетями (проверить с сетевым администратором). Файл /etc/docker/daemon.json сохранён корректно (валидный JSON). Служба Docker перезапущена после изменения конфигурации. IP-адреса контейнеров принадлежат новому пулу (шаг 6).

Клиент ПМ перестал работать после обновления Astra Linux

title: Клиент ПМ перестал работать после обновления Astra Linux slug: ts-klient-pm-posle-obnovleniya-astra tags: [Astra Linux, обновление ОС, клиент ПМ, Linux, BrokenPipeError, 401] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Клиент ПМ, ПринтМенеджер] related_pages:

kak-ustanovit-klient-pm-na-linux
ts-brokenpipe-klient-pm-linux related_errors:
"Broken pipe"
"BrokenPipeError"

Клиент ПМ перестал работать после обновления Astra Linux

Симптомы

Клиент ПМ работал корректно до обновления ОС.
После обновления Astra Linux (например, 1.7.7 → 1.7.9) задания перестали попадать в очередь ПринтМенеджер.
CUPS принимает задания (Job completed), очередь ПринтМенеджер пустая.
Служба клиента ПМ запущена.
Переустановка клиента ПМ без смены дистрибутива не помогла.

В логах одна или несколько ошибок:

BrokenPipeError: [Errno 32] Broken pipe

ipplib.IppTransportException: Error: 401

Причина

После обновления ОС изменились системные библиотеки Python или IPP-стек, с которыми взаимодействует клиент ПМ. Текущая версия дистрибутива клиента несовместима с новой версией ОС.

Переустановка того же дистрибутива проблему не решает — нужна актуальная версия клиента, совместимая с обновлённой ОС.

Диагностика

Шаг 1. Убедиться, что проблема появилась именно после обновления ОС:

cat /etc/os-release
# Зафиксировать версию Astra Linux

journalctl --since "дата обновления ОС" -u printum-printmanager-client.service | grep -i "error\|broken\|failed"

Шаг 2. Проверить, воспроизводится ли проблема на другом АРМ с той же версией ОС:

Если да — проблема системная, связана с версией ОС.

Решение

1. Запросить актуальный дистрибутив клиента ПМ в ТП, указав версию ОС (cat /etc/os-release).

2. Переустановить клиент ПМ с новым дистрибутивом:

sudo systemctl stop printum-printmanager-client.service

# Установить новую версию по инструкции из Руководства администратора

sudo systemctl status printum-printmanager-client.service

3. Проверить передачу заданий:

sudo journalctl -u printum-printmanager-client.service --since "5 minutes ago"

Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджер.

Как проверить результат

В логах нет BrokenPipeError и Error: 401.
Тестовое задание появилось в очереди ПринтМенеджер и на МФУ.

Когда эскалировать

Обновлённый дистрибутив клиента не помог.
Проблема воспроизводится не на всех АРМах после одинакового обновления ОС.
На тестовом АРМ с той же версией ОС проблема не воспроизводится — нужна более глубокая диагностика конкретного АРМ.

Приложить к заявке: версию ОС до и после обновления, версию клиента ПМ, логи journalctl с ошибкой, результат systemctl status.

Связанные страницы

Сбой активации лицензии после простоя системы

title: Сбой активации лицензии после простоя системы slug: ts-licenziya-sboy-aktivacii tags: [лицензия, сбой активации, простой, activation token] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг] related_pages:

kak-aktivirovat-ili-prodlit-licenziyu
ts-licenziya-provided-license-key related_errors:
"Provided license key instead of activation key"

Сбой активации лицензии после простоя системы

Симптомы

После длительного простоя системы (месяц и более) при входе в ЛК отображается сообщение о сбое активации. Ранее активированная лицензия перестала признаваться системой. При попытке повторно ввести лицензионный ключ — ошибка.

Причина

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

Решение

Шаг 1. Войти в ЛК (если доступ есть) → Настройки → Общие → Организации → «Токен активации». Скопировать актуальный токен.

Если ЛК недоступен из-за ошибки лицензии — обратиться в ТП напрямую, описав ситуацию. ТП восстановит доступ.

Шаг 2. Отправить токен в ТП (support@printum.io) с пояснением: система была на простое, требуется перевыпуск лицензионного ключа.

Шаг 3. Полученный новый ключ ввести в поле «Указать лицензионный ключ» → «Сохранить».

Как проверить результат

ЛК открывается без ошибки активации. В карточке организации отображаются типы лицензий и срок действия.

Когда эскалировать

ЛК полностью недоступен, нет возможности получить токен.
Новый ключ получен, но ошибка активации сохраняется.

Связанные страницы

Проблемы кластера и балансировщика

Задания не распечатываются в отказоустойчивой конфигурации

Симптом В конфигурации с балансировщиком HAProxy пользователи авторизуются, но задания не выходят на печать. Диагностика Шаг 1. Проверить панель HAProxy Откройте панель администратора HAProxy. Проверьте, что все секции зелёные: ftp cups_1631 tcp_converter_7776 / tcp_converter_7777 admin_8010 / admin_8080 Красная строка сервера = сервер установлен некорректно или недоступен. Шаг 2. Проверить флаг use_cups_ssl в клиенте ПринтМенеджер Ошибка http.client.RemoteDisconnected: Remote end closed connection without response означает неверный флаг SSL. Перейдите в директорию клиента ПМ: C:\Program Files\printum\printmanager_client\ Откройте файл settings.yml с правами администратора. Установите: use_cups_ssl: true Шаг 3. Проверить NFS-хранилище Убедитесь, что NFS-хранилище доступно со всех серверов ПринтМенеджер. Недоступность NFS приводит к потере файлов заданий. Шаг 4. Проверить синхронизацию ПринтМенеджер с Мониторингом Запустите ручную синхронизацию: Управление → ПринтМенеджеры → «Синхронизировать». Связанные страницы Файл недоступен при отложенной печати в кластере Обновление в отказоустойчивой конфигурации

Проблемы кластера и балансировщика

Файл недоступен при отложенной печати в кластере

Симптом Пользователь авторизовался на МФУ, но задание недоступно или файл документа отсутствует в очереди. Причина Файлы заданий в кластерной конфигурации хранятся на NFS-хранилище. Если NFS недоступен или неправильно смонтирован на одном из серверов ПринтМенеджер — файлы заданий не видны этому серверу. Диагностика Шаг 1. Проверить монтирование NFS # На каждом сервере ПринтМенеджер: df -h | grep nfs mount | grep nfs Шаг 2. Проверить права доступа к папке NFS ls -la /scratch # Ожидаемые права: 777, владелец nobody Шаг 3. Проверить сетевую доступность NFS-сервера ping <NFS_ADDR> # Проверка экспортов NFS: showmount -e <NFS_ADDR> Шаг 4. Перемонтировать NFS при необходимости sudo umount /scratch sudo mount <NFS_ADDR>:<NFS_FOLDER_PATH> /scratch Связанные страницы Задания не распечатываются в отказоустойчивой конфигурации

Проблемы кластера и балансировщика

Как диагностировать проблемы NFS и DNS

Назначение

DNS и NFS являются критическими зависимостями Printum.

Проблемы с ними могут вызывать:

restart loop контейнеров;
отказ ПринтМенеджер;
ошибки синхронизации;
недоступность очередей;
проблемы Встроенное приложение.

Как диагностировать проблемы DNS

Проверка resolv.conf

Проверить:

cat /etc/resolv.conf

Убедиться:

DNS-серверы доступны;
нет ошибочных записей.

Проверка hostname resolution

Проверить:

ping monitoring.local

Проверить:

hostname резолвится;
IP корректный.

Типовые признаки DNS-проблем

Симптом	Возможная причина
restart loop	hostname не резолвится
timeout	DNS unavailable
sync errors	неверный hostname
SSL errors	mismatch hostname

Как диагностировать проблемы NFS

Проверка доступности порта

Проверить:

telnet nfs-server 2049

Проверить stunnel:

telnet nfs-server 20490

Проверка mount

Проверить:

df -h

Проверить:

volume mounted;
нет stale mount;
нет readonly mode.

Проверка volumes

Проверить:

ls /var/lib/docker/volumes/

Проверка сервисов NFS

На NFS server:

systemctl status nfs-server.service

systemctl status stunnel.service

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

systemctl restart nfs-server.service

systemctl restart stunnel.service

Что делать при restart loop контейнеров

Проверить:

DNS;
NFS;
network connectivity;
mount points.

После исправления:

docker-compose down
docker-compose up -d

Что важно помнить

DNS — одна из самых частых причин отказов.
NFS критичен для работы ПринтМенеджер.
Большинство restart loop связано с инфраструктурными зависимостями.
Проверка DNS и NFS должна быть первым шагом диагностики.

MissingSchema — неверные адрес или токен ПМ (клиент ПМ Linux)

title: MissingSchema — неверные адрес или токен ПринтМенеджер (клиент ПМ Linux) slug: ts-missingschema-neverno-zadany-adres-ili-token-pm tags: [MissingSchema, клиент ПМ, Linux, адрес, токен, установка] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Клиент ПМ, ПринтМенеджер] related_pages:

kak-ustanovit-klient-pm-na-linux related_errors:
"requests.exceptions.MissingSchema: Invalid URL '/direct_printers/': No schema supplied"

MissingSchema — неверные адрес или токен ПринтМенеджер (клиент ПМ Linux)

Симптомы

Виртуальный принтер Printum не появляется на АРМ после установки клиента ПМ. В логах:

requests.exceptions.MissingSchema: Invalid URL '/direct_printers/': No schema supplied.
Perhaps you meant http:///direct_printers/?

Причина

При установке клиента ПМ переменные адреса ПринтМенеджер или access_token указаны неверно — без схемы (https://), с опечаткой или пустым значением.

Диагностика

Проверить текущие значения в конфигурационном файле:

cat /opt/printum/printmanager_client/settings.yml

Проверить:

server_url содержит полный адрес с протоколом: https://<pm_host>:8080
access_token не пустой и совпадает с токеном в панели администратора ПринтМенеджер

Решение

Переустановить клиент ПМ с корректными параметрами согласно Руководству администратора → «Установка и удаление клиента ПМ на АРМ с ОС Linux».

При установке обязательно указать:

полный адрес ПринтМенеджер с протоколом и портом: https://<адрес_пм>:8080
актуальный access_token из панели администратора ПринтМенеджер

После установки проверить:

sudo systemctl status printum-printmanager-client.service
sudo journalctl -u printum-printmanager-client.service --since "5 minutes ago"

Как проверить результат

Виртуальный принтер Printum появился на АРМ. В логах нет MissingSchema. Тестовое задание появляется в очереди ПринтМенеджер.

Когда эскалировать

Параметры указаны корректно, но ошибка сохраняется.
Клиент ПМ не запускается после переустановки.

Связанные страницы

Клиент ПМ на Linux — установка и проверка

SSL — Hostname mismatch после обновления

Симптомы

В логах ПринтМенеджер после обновления:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for '<hostname>'

Синхронизация Мониторинг–ПринтМенеджер не работает.

Причина

Сертификат выпущен для одного адреса (hostname или IP), а обращение после обновления идёт по другому. Типичные ситуации:

Во время обновления указали переменную MON_HOSTNAME, в которой допустили ошибку или указали посторонний адрес.
При установке использовался IP, а после обновления — hostname (или наоборот).
Собственный сертификат не включает нужный Subject Alternative Name.

Диагностика

Проверить, для какого адреса выпущен сертификат М:

openssl s_client -connect <адрес_М>:8001 </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

Сравнить с адресом, по которому ПринтМенеджер обращается к М:

sudo grep MONITORING_ADDRESS /opt/printmanager/.env

Если адреса не совпадают — причина найдена.

Решение

Автоматические сертификаты

В случае использования автоматических сертификатов при установке - обновление без SSL-параметров пересоздаст сертификаты автоматически:

# Для М:
sudo curl -L https://s3.printum.io/box/monitoring/install.sh | sudo -E bash
# или для офлайн метода:
sudo -E ./install.sh

# Для ПМ:
sudo curl -L https://s3.printum.io/distrib/printum-printmanager/install.sh | sudo -E bash
# или для офлайн метода:
sudo -E ./install.sh

Собственные сертификаты

Выпустить новый сертификат для актуального hostname/IP, затем обновить с указанием новых файлов:

sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \
  sudo -E SSL_CERT=/path/cert.crt SSL_KEY=/path/cert.key SSL_CERT_CA=/path/ca.crt bash -s agent

Self-signed certificate in certificate chain

Если в логах:

certificate verify failed: self signed certificate in certificate chain

Причина: в SSL-сертификат включён корневой сертификат. Использовать сертификат, содержащий только SSL-сертификат и (при необходимости) промежуточный. Корневой сертификат — отдельным файлом в SSL_CERT_CA.

Как проверить результат

cd /opt/printmanager
sudo docker-compose logs -f --tail=5

Ошибок SSL не должно быть. Синхронизация Мониторинг–ПринтМенеджер завершается успешно.

Когда эскалировать

После перевыпуска сертификата ошибка сохраняется.
Нет возможности выпустить сертификат для нужного hostname.
Инфраструктура PKI управляется заказчиком и требует его участия.

Связанные страницы

Проблемы Клиента ПМ

Принтеры не появляются на рабочей станции

Симптом После установки клиента ПринтМенеджер принтер Printum не появился в списке принтеров на АРМ пользователя. Диагностика Шаг 1. Проверить статус службы Windows: Win+R → eventvwr → Журналы Windows → Приложение → источник ПринтМенеджер Client . Linux: sudo systemctl status printum-printmanager-client.service Шаг 2. Проверить типовые ошибки в логах | Ошибка | Решение | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | No user {'login'} is authorized, removing all printers | Пользователь не существует в Printum или неверный SID. Проверьте учётную запись. | | Max retries exceeded | АРМ не достигает сервер ПринтМенеджер. Проверьте сетевую доступность и порты. | | AssertionError: Adding printer Printum means critical error | Принтер Printum не найден или неверный драйвер. Удалите принтер вручную и переустановите клиент. | Шаг 3. Проверить драйвер принтера Printum В списке принтеров Windows: принтер должен называться Printum и использовать драйвер Printum XPS . Шаг 4. Windows 7: ошибка «ОС Windows не удается подключиться к принтеру» Включите компонент «Клиент интернет-печати» : Панель управления → Программы → Включение компонентов Windows → Службы печати документов → Клиент интернет-печати. Перезагрузите компьютер. Логи и диагностические данные Где смотреть логи Клиент ПМ Windows — Отправка заданий на печать на ОС Windows Откройте eventvwr → Журналы Windows → Приложение → источник Print Manager Client Клиент ПМ Linux — Отправка заданий на печать на ОС Linux sudo journalctl -u printum-printmanager-client.service printmanager-app — Основной контейнер ПринтМенеджер — формирование списка принтеров для клиентов cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app Что искать в логах Выявить ошибки запуска сервиса клиента ПМ. Выявить ошибки передачи данных (список принтеров). Определить причины возврата кодов 4xx/5xx при запросе списка принтеров. Что приложить к обращению в поддержку Логи клиента ПМ: Windows — Просмотр событий ( eventvwr ) → Журналы Windows → Приложение → источник Print Manager Client ; Linux — sudo journalctl -u printum-printmanager-client.service Версию ПринтМенеджера: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС рабочей станции и сервера Связанные страницы Задание не появляется в очереди печати

Проблемы Клиента ПМ

Задание отправлено но не появилось на сервере

Симптом Пользователь отправил документ на принтер Printum, но задание не появилось в системе (нет в разделе «Задания» и на МФУ). Диагностика Шаг 1. Проверить логи клиента ПМ Windows: Win+R → eventvwr → источник ПринтМенеджер Client . Linux: cat /var/log/printum/printmanager_client.log Шаг 2. Проверить подключение к серверу ПринтМенеджер Ошибка HTTPSConnectionPool: Max retries exceeded — клиент не достигает сервер. Проверьте сетевую доступность адреса/порта ПринтМенеджер (8080 или 8010). Шаг 3. Проверить настройку IGNORE_USERNAME_CASE При бесклиентской печати: убедитесь, что в панели ПринтМенеджер → Системные настройки → Настройки импорта из доменов включена настройка IGNORE_USERNAME_CASE (если регистр логина на АРМ отличается от домена). Шаг 4. Проверить формат задания При использовании PostScript-режима ( USE_PS_PRINTING ): убедитесь, что драйвер на АРМ формирует PostScript-задание корректно. Связанные страницы Принтеры не появляются на рабочей станции Задание не распечатывается на принтере

Проблемы Клиента ПМ

Ошибка сертификата при установке Клиента ПМ

Симптом

Клиент ПМ не подключается к серверу ПринтМенеджер по HTTPS — ошибка проверки SSL-сертификата.

Логи и диагностические данные

Где смотреть логи

Клиент ПМ Windows — Установка на ОС Windows
Логи установки: C:\Program Files\printum\service_install_*.log, driver_install_*.log
Логи службы: eventvwr → Журналы Windows → Приложение → источник Print Manager Client

Что искать в логах

Выявить ошибки установки, связанные с сертификатами.
Выявить ошибки запуска службы после установки.

Что приложить к обращению в поддержку

Логи клиента ПМ: Windows — Просмотр событий (eventvwr) → Журналы Windows → Приложение → источник Print Manager Client; Linux — sudo journalctl -u printum-printmanager-client.service
Версию ПринтМенеджера: cat /opt/printmanager/.version
Описание сценария и шагов воспроизведения
ОС рабочей станции и сервера

Решение для Windows

Откройте корневой сертификат сервера ПринтМенеджер (printum_ca.crt или ca.crt). Скопируйте весь текст (включая -----BEGIN----- и -----END-----).
Откройте файл с правами администратора:
C:\Program Files\printum\printmanager_client\lib\certifi\cacert.pem
Вставьте скопированный текст в конец файла. Сохраните.
Перезапустите службу или перезагрузите компьютер.

Решение для Linux

systemctl stop printum-printmanager-client.service
# Добавьте CA-сертификат в конец файла:
cat /path/to/ca.crt >> /opt/printum/printmanager_client/venv/lib/python3.10/site-packages/certifi/cacert.pem
systemctl start printum-printmanager-client.service

Для более ранних версий замените python3.10 на python3.8.

Связанные страницы

Обновление сертификатов Мониторинга и ПринтМенеджера

Проблемы Клиента ПМ

Error 401 — пользователь не найден в ПМ (клиент ПМ Linux)

title: Error 401 — пользователь не найден в ПринтМенеджер (клиент ПМ Linux) slug: ts-401-polzovatel-ne-nayden-v-pm tags: [401, клиент ПМ, Linux, авторизация, пользователь, синхронизация] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Клиент ПМ, ПринтМенеджер, Мониторинг] related_pages:

kak-ustanovit-klient-pm-na-linux
kak-rabotaet-sinhronizaciya-polzovateley-s-ldap-ad

Error 401 — пользователь не найден в ПринтМенеджер (клиент ПМ Linux)

Симптомы

Задание отправлено на печать, но в очереди ПринтМенеджер не появляется. В логах клиента ПМ:

Job 00233 for Printum failed: 401 Client Error: Unauthorized for url: https://<pm_host>:8080/create_job

или:

ipplib.IppTransportException: Error: 401

Причина

Пользователь, авторизованный в ОС Linux, не существует в ПринтМенеджер, или не прошла синхронизация Мониторинг–ПринтМенеджер после добавления пользователя.

Диагностика

Шаг 1. Проверить, существует ли пользователь в ПринтМенеджер:

В панели администратора ПринтМенеджер → Пользователи: найти пользователя по имени учётной записи Linux.

Шаг 2. Проверить синхронизацию:

Если пользователь есть в М, но нет в ПринтМенеджер — не прошла синхронизация Мониторинг–ПринтМенеджер.

Шаг 3. Проверить access_token:

cat /opt/printum/printmanager_client/settings.yml | grep token

Token должен совпадать с токеном ПринтМенеджер, к которому подключён клиент.

Решение

Если пользователя нет в ПринтМенеджер:

Убедиться, что пользователь существует в М.
Запустить синхронизацию домена в М → Настройки → Интеграции → Домен.
Запустить синхронизацию Мониторинг–ПринтМенеджер: панель администратора М → ПринтМенеджеры → «Синхронизировать».
Проверить, появился ли пользователь в панели ПринтМенеджер.

Если access_token неверный:

Обновить токен в settings.yml:

sudo nano /opt/printum/printmanager_client/settings.yml
# Указать актуальный access_token из панели администратора ПМ

sudo systemctl restart printum-printmanager-client.service

Как проверить результат

Отправить тестовое задание от пользователя. Задание появляется в очереди ПринтМенеджер. В логах нет 401.

Когда эскалировать

Пользователь есть в ПринтМенеджер, токен верный, но ошибка 401 сохраняется.
Синхронизация завершается с ошибкой.

Приложить к заявке: логи клиента ПМ, версию ПринтМенеджер, имя пользователя (без персональных данных).

Связанные страницы

SSL — Hostname mismatch, certificate is not valid for '...'

title: SSL — Hostname mismatch, certificate is not valid for '...' slug: ts-ssl-hostname-mismatch tags: [ssl, hostname mismatch, сертификат, синхронизация, CUPS] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг, ПринтМенеджер, Балансировщик] related_pages:

trebovaniya-k-ssl-sertifikatam
kak-obnovit-printum related_errors:
"Hostname mismatch, certificate is not valid for '<адрес>'"
"[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:"

SSL — Hostname mismatch, certificate is not valid for '...'

Симптомы

В логах ПринтМенеджер или при установке:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
Hostname mismatch, certificate is not valid for '<адрес>'

Синхронизация Мониторинг–ПринтМенеджер не работает. CUPS не создаёт принтеры. Встроенное приложение не подключается к серверу.

Причина

Адрес, по которому компонент обращается к серверу, не совпадает с CN или Subject Alternative Name (SAN) сертификата.

Типичные ситуации:

Система установлена по hostname, а сертификат выпущен на IP (или наоборот).
После обновления изменился адрес сервера, сертификат остался старый.
При установке с балансировщиком каждому серверу нужен собственный сертификат — использовался один общий.

Диагностика

Проверить, для какого адреса выпущен сертификат:

openssl s_client -connect <адрес_сервера>:<порт> </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Сравнить с адресом, по которому идёт обращение:

# Для ПМ — адрес М в .env
grep MONITORING_ADDRESS /opt/printmanager/.env

# Для клиента ПМ на Linux
grep server_url /opt/printum/printmanager_client/settings.yml

Если адреса не совпадают — причина найдена.

Решение

Автоматические сертификаты

Переустановка без SSL-параметров пересоздаёт сертификаты автоматически под текущий адрес:

# М
sudo curl -L https://s3.printum.io/box/monitoring/install.sh | sudo -E bash

# ПМ
sudo curl -L https://s3.printum.io/distrib/printum-printmanager/install.sh | sudo -E bash

Собственные сертификаты

Перевыпустить сертификат для актуального адреса сервера. CN и SAN должны содержать адрес, по которому компонент обращается к серверу. Затем обновить с новыми файлами:

sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \
  sudo -E SSL_CERT=/path/cert.crt \
       SSL_KEY=/path/cert.key \
       SSL_CERT_CA=/path/ca.crt bash -s agent

Балансировщик

При установке с балансировщиком у каждого сервера должен быть собственный сертификат, выпущенный для его адреса. Один сертификат на все серверы не подходит.

Как проверить результат

cd /opt/printmanager
sudo docker-compose logs printmanager-celery-print-queue --tail=50 | grep -i ssl

Ошибок SSL нет. Синхронизация Мониторинг–ПринтМенеджер завершается успешно.

Когда эскалировать

После перевыпуска сертификата ошибка сохраняется.
PKI управляется заказчиком — требуется его участие.
Нет возможности выпустить сертификат для нужного hostname/IP.

Связанные страницы

Проблемы интеграций

Синхронизация Мониторинга и ПринтМенеджера не выполняется

Симптом

Изменения, сделанные в Мониторинге, не применяются на ПринтМенеджерах (пользователи, правила, принтеры не синхронизируются).

Как работает синхронизация

Мониторинг — центральный сервер, ПринтМенеджеры работают в подчинённом режиме. По умолчанию синхронизация выполняется 1 раз в час. Изменения вступают в силу не мгновенно.

Диагностика

Шаг 1. Проверить статус ПринтМенеджера в Мониторинге

Перейдите в Управление → ПринтМенеджеры. Убедитесь, что ПринтМенеджер подключён и его статус активен.

Шаг 2. Запустить синхронизацию вручную

Нажмите «Синхронизировать» в карточке нужного ПринтМенеджера или иконку синхронизации в таблице.

Шаг 3. Проверить доступность ПринтМенеджер с Мониторинга

Порты между Мониторингом и ПринтМенеджер должны быть открыты (8000, 8010, 8080).
Сертификаты должны быть актуальны с обеих сторон.

Шаг 4. Проверить Docker-контейнеры

cd /opt/printum && sudo docker-compose ps
cd /opt/printmanager && sudo docker-compose ps

Все контейнеры должны быть в статусе Up.

Связанные страницы

Расписание синхронизации с доменом

Проблемы интеграций

Ошибка подключения к почтовому серверу

Симптом

Уведомления не приходят по почте, тестовое письмо не отправляется, пользователи не могут восстановить пароль.

Диагностика

Шаг 1. Отправить тестовое письмо

Перейдите в Настройки → Интеграции → Почта. Введите адрес в поле «Почта для тестового письма» и нажмите «Отправить тестовое письмо».

Шаг 2. Проверить параметры подключения

| Параметр | Что проверить | | ----------------- | ----------------------------------------------------------------- | | SMTP-сервер | Адрес доступен с сервера Мониторинга | | Порт | Порт открыт в firewall (25, 465, 587) | | Логин/Пароль | Учётные данные корректны | | Адрес отправителя | Должен совпадать с логином (требование большинства SMTP-серверов) | | TLS/SSL | Соответствует конфигурации сервера |

Шаг 3. Проверить сетевую доступность SMTP

telnet <smtp_server> 587
# или
nc -zv <smtp_server> 587

Что проверить перед эскалацией

Тестовое письмо успешно отправлено
Порт SMTP открыт
Логин и пароль корректны

Связанные страницы

Настройка подключения к почтовому серверу

Проблемы интеграций

Лицензия истекла — что происходит и что делать

title: Лицензия истекла — что происходит и что делать slug: ts-licenziya-istekla tags: [лицензия, истёк срок, продление, годовая лицензия] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг] related_pages:

kak-aktivirovat-ili-prodlit-licenziyu

Лицензия истекла — что происходит и что делать

Симптомы

Система отправила уведомление: «Срок действия лицензии истекает» или «Срок действия лицензии истёк».
В ЛК отображается предупреждение об истечении лицензии.
Часть функционала может быть ограничена.

Что происходит при истечении лицензии

Годовые лицензии: после истечения срока ПО перестаёт функционировать. Необходимо срочное продление.

Бессрочные лицензии: включают 1 год гарантийной технической поддержки. После истечения поддержки система продолжает работать, но обновления и обращения в ТП становятся недоступны. Для восстановления поддержки — приобрести продление.

Уведомления об истечении отправляются заблаговременно — реагировать нужно до истечения, а не после.

Что делать

Продлить лицензию по стандартной процедуре:

ЛК → Настройки → Общие → Организации → «Токен активации» — скопировать токен.
Отправить в ТП: токен, название организации, текущий тип и срок лицензий, желаемый срок продления.
Получить новый лицензионный ключ и ввести через «Указать лицензионный ключ».

Если функционал уже заблокирован — указать это в обращении, ТП ускорит обработку.

Важно про перерыв в продлении

Если продление оформлено с перерывом, новый срок технической поддержки исчисляется с момента окончания предыдущего периода — а не с даты оформления. То есть перерыв не «сдвигает» начало нового периода.

Как проверить результат

ЛК → Настройки → Общие → Организации: в списке лицензий отображается обновлённый срок действия.

Когда эскалировать

Система полностью недоступна из-за истёкшей лицензии, войти в ЛК невозможно.
Новый ключ введён, но срок не обновился.

Обратиться напрямую: support@printum.io — указать название организации и идентификатор.

Связанные страницы

Как активировать или продлить лицензию

Проблемы интеграций

Как обновить SSL-сертификаты Printum

title: Как обновить SSL-сертификаты Printum slug: ts-ssl-obnovlenie-sertifikatov tags: [ssl, сертификат, обновление, истёк срок, балансировщик] domain: Operations type: Runbook audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг, ПринтМенеджер, Балансировщик] related_pages:

trebovaniya-k-ssl-sertifikatam
kak-obnovit-printum

Как обновить SSL-сертификаты Printum

Когда использовать

Истёк срок действия сертификатов.
Изменился hostname или IP-адрес сервера.
Требуется заменить сертификаты по требованиям ИБ.

Singlenode: обновление сертификатов М

sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \
  sudo -E SSL_CERT=/path/cert.crt \
       SSL_KEY=/path/cert.key \
       SSL_CERT_CA=/path/ca.crt bash -s agent

Singlenode: обновление сертификатов ПринтМенеджер

sudo curl -L https://s3.printum.io/distrib/printum-printmanager/install.sh | \
  sudo -E SSL_CERT=/path/cert.crt \
       SSL_KEY=/path/cert.key \
       SSL_CERT_CA=/path/ca.crt bash

Балансировщик: обновление собственных сертификатов через скрипт

В файле config.ini обновить пути к новым сертификатам:

[General]
SSL_CERT_CA = /path/to/new/ca.crt

[Balancer]
SSL_CERT = /path/to/balancer/cert.crt
SSL_KEY  = /path/to/balancer/cert.key

[Monitoring]
SSL_CERT = /path/to/monitoring/cert.crt
SSL_KEY  = /path/to/monitoring/cert.key

[PrintManager_1]
SSL_CERT = /path/to/pm1/cert.crt
SSL_KEY  = /path/to/pm1/cert.key

# [PrintManager_2], [PrintManager_3] — аналогично

Запустить скрипт:

sudo ./install_all_offline.sh

Балансировщик: перевыпуск автоматических сертификатов

Выполнять на сервере балансировщика раз в год:

# Удалить все сертификаты
sudo rm -fr /opt/printum_balancer/certificates

# Выпустить новый корневой сертификат
sudo /opt/printum_balancer/scripts/generate_ca_cert.sh

# Перевыпустить сертификаты для всех серверов
cd /opt/printum_balancer/scripts
sudo ./regenerate_all_certs.sh \
  -balancer <BALANCER_ADR> \
  -pm <PM_1> \
  -pm <PM_2> \
  -pm <PM_3>

Где <BALANCER_ADR>, <PM_1>, <PM_2>, <PM_3> — те же адреса, что использовались при первоначальной установке.

Проверка после обновления

# Проверить срок действия нового сертификата М
openssl s_client -connect <адрес_М>:8001 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

# Проверить синхронизацию М–ПМ
cd /opt/printmanager
sudo docker-compose logs printmanager-celery-print-queue --tail=50 | grep -i ssl

Ошибок SSL нет. Синхронизация завершается успешно.

Когда эскалировать

Обновление сертификатов не устраняет SSL-ошибки.
Цепочка доверия не проходит проверку.
PKI управляется заказчиком.

Связанные страницы

Диагностика и сбор логов

Модель диагностики Принтум

Что такое модель диагностики

Диагностика в Printum строится по трёхшаговой модели. Цель модели — не перебирать логи наугад, а сначала сузить зону поиска, потом определить конкретное звено в цепочке компонентов, и только затем смотреть логи именно там.

Главный принцип: сначала понять, где проблема — в системе или в инфраструктуре. Потом в какой части системы. Потом смотреть логи.

Три шага модели

| Шаг | Вопрос | Результат | | ------------------------- | -------------------------------------------------- | -------------------------------------------------------- | | Шаг 1. Локализация | Система или инфраструктура? | Понимаем, стоит ли вообще смотреть в Printum | | Шаг 2. Сценарий и условия | Что именно происходит, у кого, при каких условиях? | Паспорт инцидента: сценарий, масштаб, воспроизводимость | | Шаг 3. Карта системы | Какие компоненты участвуют в этом сценарии? | Конкретный контейнер или служба, которую нужно проверить | | Шаг 4. Логи | Что написано в логах целевого компонента? | Причина проблемы или следующая гипотеза |

Почему именно в таком порядке

Если начать с логов без локализации — потратите время на правильные логи, в которых нет ошибки, потому что проблема вообще за пределами системы. Если не определить сценарий — непонятно, в каком именно контейнере из десятка искать.

Тимур Гусев (встреча по архитектуре): «Если инженер умеет читать поток данных, он сможет диагностировать систему в любом проекте — в самом лёгком и в самом сложном».

Связанные страницы

Диагностика и сбор логов

Шаг 1 — Локализация: система или инфраструктура?

Цель шага

Понять: проблема находится внутри системы Printum или вне её — в инфраструктуре, сети, настройке принтера, драйвере.

Если проблема вне системы — дальнейшая диагностика Printum не нужна.

Методы проверки

1. Печать мимо системы

Отправьте задание печати напрямую на принтер, минуя Printum: установите принтер как обычный сетевой принтер Windows/Linux и распечатайте тестовую страницу.

Печатает → принтер работает, проблема в системе Printum
Не печатает → проблема в принтере, драйвере или сети

2. Другой принтер

Воспроизведите то же действие на другом устройстве того же типа или в другом подразделении.

На другом работает → проблема связана именно с этим устройством: настройки, доступность по сети, SNMP
На всех не работает → системная причина или инфраструктурная: сеть, домен, конфигурация

3. Другой пользователь

Попросите другого сотрудника воспроизвести проблему под своей учётной записью.

У другого работает → проблема привязана к конкретной УЗ: права, правила печати, карта, домен
У всех не работает → системная или групповая причина

4. snmpwalk

Выполните опрос устройства по SNMP вручную, чтобы проверить доступность и ответ принтера.

snmpwalk -v2c -c public <IP_принтера> 1.3.6.1.2.1.1

Получен ответ → принтер доступен по SNMP, данные могут поступать в систему
Нет ответа / timeout → проблема в сети, SNMP не настроен, community-строка не совпадает, устройство недоступно

Сетевой агент Printum опрашивает устройства по порту 161 и получает ответ по порту 162 (протокол SNMP). Если snmpwalk не отвечает — агент тоже не получит данных.

Результат шага

После проверки становится ясно:

Проблема в инфраструктуре → передать в соответствующую команду
Проблема в системе Printum → переходим к Шагу 2

Связанные страницы

Шаг 2 — Определение сценария и условий

Диагностика и сбор логов

Шаг 2 — Определение сценария и условий

Цель шага Точно описать, при каких условиях и у кого проявляется проблема, прежде чем искать её в системе. Чем точнее паспорт инцидента, тем быстрее находится нужный компонент. Сценарий Определите, какой именно процесс не работает: | Категория | Варианты | | -------------------------- | ---------------------------------------------------------------- | | Печать | прямая / отложенная; с клиентом ПринтМенеджер / без клиента (бесклиентская) | | Авторизация | PIN / карта / внешняя авторизация | | Отчёты | веб / файл (Excel) / почта | | Синхронизация | ручная / по расписанию (домен, М→ПринтМенеджер) | | Сканирование / Копирование | через встроенное приложение | Сценарий определяет, какие компоненты участвуют в процессе и где искать разрыв. Условия Зафиксируйте технические характеристики окружения: Версия системы — версия Мониторинга и/или ПринтМенеджера ОС сервера — на чём развёрнута система Контроллер домена — используется или нет, версия AD/LDAP Конфигурация — single (один сервер) / cluster (с балансировкой) / филиальная сеть Масштаб Сколько объектов затронуто — это ключ к поиску общего знаменателя. | Объект | Варианты | Что искать при группе | | ------------ | ------------------- | ---------------------------------------- | | Устройства | одно / группа / все | локация, вендор, модель, подсеть | | Пользователи | один / группа / все | подразделение, OU, тип авторизации, роль | | Документы | один / группа / все | формат, размер, программа-источник | Если проблема у группы — ищите что объединяет эту группу: одна локация, один вендор устройств, одна OU в домене. Воспроизводимость Всегда — ошибка стабильная, легче диагностировать: запускаем сценарий и сразу видим в логах Иногда — нестабильная ошибка; нужно включить режим DEBUG и воспроизводить повторно, или смотреть частоту в логах за период Результат шага Заполненный Паспорт инцидента с описанием сценария, условий, масштаба и воспроизводимости. На основе этих данных строим карту системы. Связанные страницы Шаг 1 — Локализация: система или инфраструктура? Шаг 3 — Карта системы и где искать проблему Паспорт инцидента

Диагностика и сбор логов

Классификация инцидентов и мониторинг состояния системы

Назначение

Инструкция описывает порядок действий дежурных администраторов при возникновении инцидентов в системе Принтум и связанных компонентах. Основана на отказоустойчивой архитектуре системы и процессах мониторинга.

Классификация инцидентов

События уровня инфраструктуры

Нет связи с сервером Мониторинга, ПринтМенеджера, HAProxy (не удаётся зайти в Личный кабинет, панели администратора);
События связаны с ресурсами ВМ;
Ошибки доступа к БД;
Недоступность NFS или stunnel;
Ошибки сети.

События уровня сервисов Принтум

Не работает печать;
Отсутствуют задания в очереди;
Постоянный перезапуск контейнеров;
В приложении на МФУ ошибка: «Сервер ПринтМенеджера недоступен».

Обнаружение инцидента

Обнаружение инцидента происходит в панели администратора балансировщика HAProxy (https://<адрес_сервера>:7000).

Строки компонентов окрашиваются в цветные статусы в зависимости от результата проверки healthcheck:

Цвет	Значение
Ярко-зелёный	Компонент работает стабильно, проверка healthcheck прошла успешно.
Светло-зелёный	Компонент уходит в отказ, проверка healthcheck прошла успешно.
Жёлтый	Компонент восстанавливается из отказа, проверка healthcheck прошла успешно.
Красный	Компонент находится в отказе, либо проверка healthcheck прошла не успешно.

При ярко-зелёном статусе компонентов дополнительное внимание не требуется. При светло-зелёном, жёлтом и красном статусе рекомендуется проверить состояние конкретного компонента на соответствующем сервере ПринтМенеджера.

Время реакции и решения

Инфраструктурные события

События, связанные с инфраструктурой, относятся к критическим неисправностям, напрямую влияющим на сервис печати.

Признаки остановки сервиса печати ПринтМенеджера

Недоступность сервисов admin_8080, admin_8010, cups_1631 на панели администратора HAProxy:

Недоступность на 1 сервере — некритично, требует внимания.
Недоступность на 2 серверах — критичный отказ сервиса.

В панели администратора HAProxy существует колонка, отвечающая за мониторинг времени последнего ответа от сервиса. Лимит ответа — 10 секунд. Если за это время сервис не дал ответ, статус изменит цвет.

Параметр	Значение
Время реакции	до 5 минут
Время решения	до 30 минут
Эскалация	сразу при обнаружении

Сервисные события

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

Параметр	Значение
Время реакции	до 15 минут
Время решения	до 2 часов
Эскалация	при ухудшении состояния

Проверка доступности сервисов

Подключиться по SSH.
Перейти в каталог нужного сервера:

ПринтМенеджер:

cd /opt/printmanager/

Мониторинг:

cd /opt/printum/

Балансировщик:

cd /opt/printum_balancer/

Проверить контейнеры:

docker ps

Диагностика и сбор логов

Шаг 4 — Сбор и чтение логов

Уровни логов | Уровень | Значение | Что делать | | ------- | ----------------------------------------------------- | -------------------------------------------------------- | | ERROR | Произошла ошибка, операция не выполнена | Искать причину — читать сообщение и контекст вокруг | | WARNING | Подозрительное состояние, система продолжает работать | Оценить как подозрение — может быть предвестником ошибки | | INFO | Штатное событие, контекст происходящего | Использовать как фон для понимания последовательности | | DEBUG | Детальные данные для диагностики | Включается вручную — даёт максимум деталей | Как читать запись лога Каждая строка лога имеет структуру: [container_name] [timestamp] [LEVEL] [message] Пример: printum_worker-default | 2024-01-15 10:23:41,012 ERROR [apps.inv.services.sync:302]: Some snmp data missing for printer 1 Контейнер — printum_worker-default : в каком компоненте произошло событие Время — 2024-01-15 10:23:41 : когда произошло Уровень — ERROR : насколько критично Сообщение — текст с модулем и строкой кода: что произошло Ключевые сигналы ERROR → ищите причину: читайте строки до и после, проверяйте traceback WARNING → подозрение: само по себе не критично, но указывает направление поиска traceback (Python) → ошибка уровня разработки, передавать в разработку вместе с логами Частота — одна ошибка или тысячи? Массовые ошибки за короткий период говорят об иной природе проблемы Периодичность — ошибка возникает каждые N минут? Скорее всего связана с планировщиком (Celery scheduler) Режимы логирования Два типа логов: Логи работы — описывают процессы и операции в системе в реальном времени Логи установки — фиксируют этапы установки и настройки Два режима: Стандартный — базовые записи (LOG_LEVEL=WARNING по умолчанию) DEBUG — детальные записи для диагностики, включается вручную Команды сбора логов Архивный сбор логов (рекомендуется при обращении в поддержку) Если установлен Мониторинг и ПринтМенеджер, или только Мониторинг: bash /opt/printum/logs.sh Если установлен только ПринтМенеджер: bash /opt/printmanager/logs.sh Если файл .env зашифрован: sudo -E ENV_VAULT_PASSWORD= bash /opt/printum/logs.sh Архив сохраняется в /opt/.../ALL_LOGS/logs-<YYYY-MM-DD-HH-MM-SS>.tar.gz Просмотр логов в реальном времени Все контейнеры сразу: cd /opt/printum sudo docker-compose logs -f --tail=1 Или для ПринтМенеджер: cd /opt/printmanager sudo docker-compose logs -f --tail=1 Узнать названия контейнеров: sudo docker-compose ps --services Логи конкретного контейнера: sudo docker-compose logs -f converter_server Включение режима DEBUG Перейдите в директорию продукта: cd /opt/printum/ # или cd /opt/printmanager/ Откройте файл конфигурации: sudo nano .env Измените параметры: DEBUG=True LOG_LEVEL=DEBUG Перезапустите контейнеры: sudo docker-compose down sudo docker-compose up -d После сбора логов обязательно верните параметры в исходное состояние ( DEBUG=False , LOG_LEVEL=WARNING ) и перезапустите контейнеры, чтобы избежать снижения производительности. Сетевой агент Текущий лог: cat /opt/printum-agent/agent.log Включение DEBUG для агента: sudo nano /opt/printum-agent/config.env # Установите: LOG_LEVEL=DEBUG sudo systemctl restart printum-agent.service Архивные логи агента: /opt/printum-agent/agent-.log.gz Локальный агент Linux sudo journalctl -u printum-jtm.service Клиент ПМ для Linux sudo journalctl -u printum-printmanager-client.service Файлы логов клиента: /var/log/printum/printmanager_client.log Клиент ПМ для Windows и локальный агент Windows Откройте Просмотр событий: Win+R → eventvwr . В левой панели: «Журналы Windows» → «Приложение». Источник для клиента ПМ: ПринтМенеджер Client . Источник для локального агента: ServicePrintum . Связанные страницы Шаг 3 — Карта системы и где искать проблему Паспорт инцидента

Диагностика и сбор логов

Паспорт инцидента

Назначение

Паспорт инцидента — шаблон для сбора всей необходимой информации до начала диагностики. Заполняется на Шаге 2 модели диагностики. Позволяет быстро передать инцидент коллеге или в поддержку без потери контекста.

Шаблон паспорта инцидента

| Поле | Что указать | Пример | | ---------------------- | --------------------------------------------------- | ---------------------------------------------------------------- | | Сценарий | Что не работает и в каком режиме | Отложенная печать с клиентом ПринтМенеджер | | Версия системы | Версия Мониторинга и/или ПринтМенеджера | Мониторинг 4.5.1, ПринтМенеджер 3.2.0 | | ОС сервера | Операционная система, на которой развёрнута система | Ubuntu 22.04 | | Конфигурация | Тип развёртывания | single / cluster / филиал | | Контроллер домена | Используется или нет, тип и версия | Active Directory, Windows Server 2019 | | Масштаб — устройства | Одно / группа / все. Если группа — что объединяет | Два принтера Kyocera в офисе №3 | | Масштаб — пользователи | Один / группа / все. Если группа — что объединяет | Все пользователи из OU=Бухгалтерия | | Масштаб — документы | Один / группа / все. Если группа — что объединяет | Только PDF-файлы из Adobe Reader | | Воспроизводимость | Всегда / иногда. Если иногда — при каких условиях | Иногда, обычно после 17:00 | | Симптомы | Что именно видит пользователь, сообщение об ошибке | «Задание отправлено, но не печатается», ошибки нет | | Уже проверено | Какие шаги диагностики уже выполнены | Печать мимо системы работает, другой пользователь — та же ошибка | | Логи приложены | Какие логи собраны и приложены | logs-2024-01-15-10-30-00.tar.gz (архив /opt/printum/logs.sh) |

Как использовать

Заполните шаблон до начала диагностики — это займёт 5 минут и сэкономит часы
Используйте как чек-лист: все поля заполнены → можно переходить к Шагу 3
При передаче в поддержку — приложите заполненный паспорт и архив логов

Связанные страницы

Диагностика и сбор логов

Как диагностировать проблемы печати по этапам

Кратко

Проблемы печати нужно диагностировать не по общему описанию «не печатает», а по этапу, на котором остановилось задание. Правильная диагностика начинается с определения сценария и поиска точки отказа в цепочке обработки.

Первичные вопросы для локализации

Вопрос	Зачем нужен
Клиент ПМ или бесклиентская печать?	Разные точки входа и места диагностики
Прямая или отложенная печать?	Разный путь после обработки задания
Какой пользователь и на какое устройство?	Проверка прав, правил, лицензий, PIN/карты
Проблема у одного или у всех?	Помогает понять: системная проблема или локальная
Проблема стабильно воспроизводится?	Отличить системный сбой от случайного

Шаг 1. Определить, появилось ли задание в Принтум

Откройте раздел Управление → Задания.

Если задания нет

Искать проблему до попадания задания в ПринтМенеджер:

Сценарий	Где искать
Клиент ПМ	Локальная очередь, служба Клиента ПМ, подключение к ПринтМенеджеру
Бесклиентская печать	Виртуальный принтер, универсальный драйвер, доступность CUPS ПринтМенеджера

Если задание есть

Искать проблему после попадания в ПринтМенеджер: правила, лицензии, CUPS, драйвер устройства, протокол, Встроенное приложение, физическое устройство.

Шаг 2. Для Клиента ПринтМенеджер — проверить рабочую станцию

Windows

Откройте eventvwr.
Перейдите в Журналы Windows → Приложение.
Найдите события с источником ПринтМенеджер Client.
Проверьте красные и жёлтые ошибки.

Дополнительно проверьте:

служба Клиента ПринтМенеджер запущена;
виртуальный принтер Принтум существует;
пользователь существует в Принтум;
Клиент ПМ достигает сервер ПринтМенеджера;
access token указан корректно.

Linux

sudo systemctl status printum-printmanager-client.service
sudo journalctl -u printum-printmanager-client.service

Шаг 3. Для бесклиентской печати — проверить CUPS

Проверьте:

виртуальный принтер на рабочей станции;
универсальный PostScript-драйвер;
адрес сервера Принтум в настройках принтера;
поступление задания в CUPS ПринтМенеджера.

Шаг 4. Если задание появилось, но не печатается

Проверьте CUPS ПринтМенеджера:

Откройте: https://<ip_сервера>:1631
Перейдите на вкладку Задания.
Найдите задание и проверьте его статус.

Если статус не «напечатано» — проблема может быть в сетевой доступности принтера, протоколе подключения, драйвере, настройках CUPS или самом устройстве.

Шаг 5. Для отложенной печати — дополнительные проверки

Пользователь авторизуется на МФУ.
Встроенное приложение установлено и активировано.
У устройства есть лицензия EMB.
Пользователь видит свою очередь.
Задание принадлежит этому пользователю.
Правила печати не запрещают выпуск.

Шаг 6. Проверить правила печати

Проверьте персональные и групповые правила пользователя:

правила по цветности;
правила по количеству страниц;
правила автоудаления после печати;
квоты пользователя.

Важно для бесклиентской печати: настройка USE_PS_PRINTING влияет на конвертацию. Если есть правила по страницам, цветности или автоудалению — задание принудительно конвертируется в PDF.

Шаг 7. Проверить лицензии

Сценарий	Лицензия
Мониторинг устройства	M
Управление печатью	PM
Встроенное приложение	EMB
Внешняя авторизация	EXT

Шаг 8. Проверить синхронизацию с Мониторингом

Изменения в пользователях, правилах, лицензиях или устройствах вступают в силу только после синхронизации Мониторинга и ПринтМенеджера. При необходимости выполните ручную синхронизацию.

Типовые развилки диагностики

Наблюдение	Вероятная зона проблемы
Задания нет в Принтум	Рабочая станция, Клиент ПМ, виртуальный принтер, CUPS входящего задания
Задание есть, но не печатается	CUPS, драйвер, протокол, устройство
Задание есть, пользователь не видит его на МФУ	Авторизация, принадлежность задания, Встроенное приложение
Работает у одного, не работает у другого	Пользователь, права, правила, карта, PIN
Работает на одном принтере, не работает на другом	Устройство, лицензии, драйвер, протокол
Не работает ни у кого	Сервер, сеть, ПринтМенеджер, CUPS, синхронизация

Что собрать перед эскалацией

Сценарий: Клиент ПМ или бесклиентская печать.
Тип печати: прямая или отложенная.
Пользователь и устройство.
Время воспроизведения.
Появилось ли задание в разделе Управление → Задания.
Статус службы Клиента ПринтМенеджер (если применимо).
Статус задания в CUPS.
Логи Клиента ПринтМенеджер или ПринтМенеджера.
Применённые правила и наличие лицензий.
Результат ручной синхронизации (если менялась конфигурация).

Связанные страницы

Диагностика и сбор логов

Диагностика отказа Мониторинга

Назначение

Инструкция описывает диагностику отказа Мониторинга в Принтум. Мониторинг отвечает за: управление системой, SNMP-мониторинг, пользователей, синхронизацию, статистику и отчеты.

Признаки проблемы

Недоступен веб-интерфейс;
Ошибки синхронизации;
Не обновляется статистика;
Ошибки Встроенного приложения;
Недоступна панель администратора.

Последовательность диагностики SSH → гипервизор → перезагрузка → backup

Шаг 1. Проверка SSH-доступа

Попробуйте подключиться к серверу по SSH:

ssh admin@server

Если подключение успешно, проверьте состояние контейнеров:

sudo docker ps -a

Шаг 2. SSH недоступен — подключение через гипервизор

Подключитесь к виртуальной машине через гипервизор. Если вход выполнен:

Проверьте сетевой стек.
Проверьте DNS-настройки.
Исправьте найденные ошибки.

Шаг 3. В терминал войти не удалось — перезагрузка ВМ

Выполните перезапуск виртуальной машины.
Дождитесь загрузки ОС.
Проверьте контейнеры:

sudo docker ps -a

Шаг 4. ОС не загрузилась — восстановление из резервной копии

Выполните попытки связи с ответственным инженером.
При отсутствии результата восстановите ВМ из резервной копии.

Диагностика при успешном SSH-доступе

Проверка логов контейнеров

cd /opt/printum

docker-compose logs -f --tail=100

Проверить: ошибки PostgreSQL, ошибки DNS, SSL errors, traceback, connection refused.

Проверка ресурсов

htop

df -h

Проверка DNS

ping monitoring.local

cat /etc/resolv.conf

Перезапуск контейнеров Мониторинга

Если ошибок инфраструктуры нет:

cd /opt/printum
docker-compose down
docker-compose up -d

Если проблема сохраняется — перезагрузите ОС. Если проблема сохраняется после перезагрузки — обратитесь к Руководству администратора, раздел «Работа с логами».

Высокая загрузка CPU / RAM

Подключиться по SSH.
Определить процесс с высокой нагрузкой:

htop

Если нагружает вспомогательный сервис (например, антивирус):

systemctl stop <имя_сервиса>

Если остановка не выполнена, найти PID:

ps aux | grep <имя_сервиса>

Завершить принудительно:

kill -9 <PID>

Проверить, что статусы сервисов в HAProxy зелёные.

Типовые проблемы

Симптом	Возможная причина
restart loop	DNS/NFS
Нет UI	Контейнер API не работает
Ошибки sync	PostgreSQL
SSL errors	Сертификаты
timeout	Network issue

Что важно помнить

Мониторинг не участвует напрямую в обработке печати.
ПринтМенеджер может продолжать локальную работу.
Большинство проблем связано с инфраструктурой.
DNS является критически важной зависимостью.

Диагностика и сбор логов

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

Назначение

DNS и NFS являются критическими зависимостями Принтум. Проблемы с ними могут вызывать: restart loop контейнеров, отказ ПринтМенеджера, ошибки синхронизации, недоступность очередей, проблемы Встроенного приложения.

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

Проверка resolv.conf

cat /etc/resolv.conf

Убедиться: DNS-серверы доступны, нет ошибочных записей. При необходимости скорректировать файл /etc/resolv.conf.

Проверка hostname resolution

ping monitoring.local

Проверить: hostname резолвится, IP корректный.

Типовые признаки DNS-проблем

Симптом	Возможная причина
restart loop	hostname не резолвится
timeout	DNS unavailable
sync errors	неверный hostname
SSL errors	mismatch hostname

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

Проверка доступности порта

telnet <hostname_nfs> 2049

Проверка stunnel:

telnet <hostname_nfs> 20490

Проверка mount

df -h

Проверить точку монтирования:

ls /var/lib/docker/volumes/printmanager_media/_data

Убедиться: volume mounted, нет stale mount, нет readonly mode.

Проверка volumes

ls /var/lib/docker/volumes/

Проверка сервисов на сервере NFS

Подключиться по SSH к серверу NFS.

Проверить место:

df -h

Проверить сервисы:

systemctl status nfs-server.service

systemctl status stunnel.service

Перезапуск сервисов NFS

systemctl restart nfs-server.service

systemctl restart stunnel.service

Проверить зелёный статус сервисов в HAProxy.

Что делать при restart loop контейнеров

Проверить: DNS, NFS и stunnel, точки монтирования, сетевую связность.

После исправления:

sudo docker-compose down
sudo docker-compose up -d

Если проблема на нескольких серверах ПринтМенеджера — остановку и запуск выполнить на всех нодах. Убедиться, что статусы в HAProxy зелёные. Если проблема сохраняется — восстановить сервер из резервной копии.

Нехватка места на диске

Очистка журналов ОС

sudo journalctl --vacuum-size 1M

sudo rm -rf /var/log/messages-*

df -h

Поиск больших логов Docker

sudo du -ch /var/lib/docker/containers/*/*-json.log

sudo truncate -s 0 <путь_к_файлу>

sudo df -h

Что важно помнить

DNS — одна из самых частых причин отказов.
NFS критичен для работы ПринтМенеджера.
Большинство restart loop связано с инфраструктурными зависимостями.
Проверка DNS и NFS должна быть первым шагом диагностики.

Диагностика и сбор логов

Чек-лист перед обращением в техническую поддержку

Описание Для получения качественной и быстрой помощи в обращении необходимо указать версии всех компонентов системы и собрать логи. Ниже описаны проверки работоспособности системы. Рекомендуется использовать после установки системы, крупных обновлений и при исправлении ошибок. Чек-лист корректности настройки системы мониторинга Найдены все устройства в сети. У всех принтеров и МФУ корректно отображаются модели. По всем принтерам и МФУ корректно отображаются серийные номера. По всем цветным принтерам и МФУ отображаются показания цветного счётчика. По всем принтерам подгружаются запчасти из базы (корректные русские названия, тип — «расходные материалы» или «ресурсные запчасти»). По всем принтерам есть данные по оставшемуся ресурсу расходных материалов, полученных от устройства (в столбце «Оставшийся ресурс» для деталей с типом «Расходные материалы» отображается иконка «принтер»). Нет запчастей с типом «Другое». Не отображаются одновременно несколько картриджей одного цвета и разной ёмкости. Как определить версии компонентов Мониторинг и ПринтМенеджер В терминале сервера введите команды: cat /opt/printum/.version cat /opt/printmanager/.version Клиент ПМ (Windows) Перейдите в папку с Клиентом ПМ: C:\Program Files\printum\printmanager_client\ Откройте свойства файла as_service.exe . Перейдите во вкладку «Подробно» . В графе «Версия файла» указана версия программы. Сбор логов Мониторинг и ПринтМенеджер Если установлен Мониторинг и ПринтМенеджер или только Мониторинг: bash /opt/printum/logs.sh Если установлен только ПринтМенеджер: bash /opt/printmanager/logs.sh Если Мониторинг или ПринтМенеджер установлен с включённым шифрованием .env : sudo -E ENV_VAULT_PASSWORD= bash /opt/printum/logs.sh или sudo -E ENV_VAULT_PASSWORD= bash /opt/printmanager/logs.sh После завершения выводится сообщение вида: Логи успешно собраны и сохранены в /путь_к_каталогу/ALL_LOGS/logs-2023-12-06-17-14-44.tar.gz Собранные логи сохраняются в папке ALL_LOGS в виде архивов. При повторном запуске команды создаются новые архивы — ранее сформированные файлы не перезаписываются. Включение режима DEBUG Перейдите в директорию нужного продукта: Мониторинг: cd /opt/printum/ ПринтМенеджер: cd /opt/printmanager/ Откройте файл .env : sudo nano .env Измените параметры: DEBUG=True LOG_LEVEL=DEBUG Перезапустите контейнеры: sudo docker-compose down && sudo docker-compose up -d Что указать в обращении Версии всех компонентов: Мониторинг, ПринтМенеджер, Клиент ПМ. Архив с логами. Описание симптомов и шагов для воспроизведения. Модель и IP-адрес устройства (при проблемах с конкретным МФУ). Ошибки идентификации из столбца «Ошибки идентификации» (при проблемах с обнаружением).

Диагностика и сбор логов

Справочник контейнеров — когда и что смотреть в логах

Контейнеры Мониторинга Команды выполняются из директории /opt/printum . Контейнер Описание Когда анализировать (симптомы) Цель анализа Команда printum_nginx HTTP-сервер и обратный прокси-сервер. Проксирует все HTTP-соединения от/до приложения, отдаёт статику. Ошибки при загрузке Личного кабинета или он не загружается. Ошибки при загрузке панели администратора Мониторинга или она не загружается. Принтеры не добавляются в Мониторинг или не обновляют данные. Не происходит синхронизация между Мониторингом и ПринтМенеджером. Выявить какие именно URL вызывают ошибки. Выявить коды ошибок. Выявить коды ошибок при запросах от сетевого агента. Выявить коды ошибок при запросах от ПринтМенеджера. cd /opt/printum docker-compose logs -f --tail=200 printum_nginx printum_dashboard Логи Личного кабинета. При загрузке Личного кабинета происходят ошибки. Пользователь не может открыть страницу ЛК в браузере. Выявить какие именно URL вызывают ошибки. Выявить коды ошибок. Выявить какой IP-адрес пытается получить данные. cd /opt/printum docker-compose logs -f --tail=200 printum_dashboard printum_worker-default printum_worker-high printum_worker-low Воркеры мониторинга. Три очереди Celery для выполнения фоновых задач: отправка писем, обработка данных от принтеров. Проблемы с отправкой писем. Проблемы с обработкой данных от принтеров. Не обновляется статус принтера. Не обновляется история замен. Проблемы с синхронизацией Мониторинга и ПринтМенеджера. Не обновляется информация по принтерам. Не загружаются справочники. Не приходят уведомления на почту. Данные в Мониторинге появляются с большой задержкой. Фоновые операции выполняются нестабильно или не завершаются. Выявить в какое время была запущена очередная задача. Выявить в какое время была завершена очередная задача. Выявить время выполнения задачи. Выявить наличие ошибок по периодическим задачам. cd /opt/printum docker-compose logs -f --tail=200 printum_worker-default docker-compose logs -f --tail=200 printum_worker-high docker-compose logs -f --tail=200 printum_worker-low printum_scheduler Планировщик задач для Celery. Выполняет задачи мониторинга по расписанию. Не выполняются задачи по расписанию (например, не запускается синхронизация с доменом). Не приходят уведомления на почту. Не обновляются данные, которые должны обновляться по расписанию. Выявить, запускается ли задача по расписанию. Выявить ошибки планировщика при постановке задач в очередь. cd /opt/printum docker-compose logs -f --tail=200 printum_scheduler printum_backend API мониторинга. Все не фоновые задачи. Не работает отправка писем. Проблемы с созданием локаций. Проверка обмена данными с Локальным агентом. Ошибки при работе Личного кабинета (действия не выполняются). Выявить ошибки обработки API-запросов. Определить причины возврата кодов 4xx/5xx. Выявить некорректные входные данные запросов. Определить, на каком этапе происходит ошибка (валидация / логика / БД). cd /opt/printum docker-compose logs -f --tail=200 printum_backend printum_clickhouse Столбцовая система управления базами данных. Обычно смотреть не нужно. Проверка запуска сервиса. Наличие ошибок запуска БД. Проверить наличие ошибок запуска БД. cd /opt/printum docker-compose logs -f --tail=200 printum_clickhouse printum_redis Брокер сообщений мониторинга. Проверка запуска сервиса. Наличие ошибок запуска сервиса. Проверить наличие ошибок запуска сервиса. cd /opt/printum docker-compose logs -f --tail=200 printum_redis printum_postgres База данных мониторинга. Проверка запуска сервиса. Наличие ошибок запуска БД. Проверить наличие ошибок запуска БД. cd /opt/printum docker-compose logs -f --tail=200 printum_postgres Контейнеры ПринтМенеджера Команды выполняются из директории /opt/printmanager . Контейнер Описание Когда анализировать (симптомы) Цель анализа Команда printmanager_web Админка ПринтМенеджер, nginx. Проксирует все HTTP-соединения для ПринтМенеджера. Не происходит синхронизация между Мониторингом и ПринтМенеджером. Выявить какие именно URL вызывают ошибки. Выявить коды ошибок. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager_web printmanager-celery Все фоновые задачи ПринтМенеджер. Обрабатывает интеграцию с Мониторингом, задания печати, встроенные приложения. Не импортируются принтеры из Мониторинга. Не отправляется статистика печати в Мониторинг. Задания печатаются с большой задержкой или не печатаются вовсе. Печатается только часть задания. Ошибки установки или деинсталляции встроенного приложения. Выявить ошибки при интеграции с Мониторингом. Выявить ошибки при печати заданий. Выявить ошибки при установке встроенного приложения. Выявить ошибки при соединении с CUPS. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-celery printmanager-celery-print-queue Очередь бесклиентской печати. Проверяет CUPS на наличие новых заданий и отправляет их на обработку и печать. Задания не попадают в очередь печати или попадают с большой задержкой. Выявить ошибки соединения с CUPS. Выявить ошибки при обработке заданий из CUPS. Выявить ошибки соединения с принтерами. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-celery-print-queue printmanager-scheduler Планировщик задач для Celery ПринтМенеджер. Механизм отправки задач по расписанию. Задания перестали приходить в очередь печати. Задания гостевой печати перестали приходить в очередь. Задания печати через почту перестали приходить в очередь. У заданий образы документов не появляются. Выявить, запускается ли задача по расписанию. Выявить ошибки планировщика при постановке задач в очередь. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-scheduler printmanager-app Основной контейнер ПринтМенеджер. Django-приложение административной панели. Обрабатывает все HTTP-обращения, принтеры, клиентов. Проблемы с печатью / копированием / сканированием. Проблемы с авторизацией. Задания не приходят на устройство, хотя в ПринтМенеджере есть. Проверка обмена данными с Клиентом ПМ. Выявить ошибки обработки API-запросов. Определить причины возврата кодов 4xx/5xx. Выявить некорректные входные данные запросов. Определить, на каком этапе происходит ошибка (валидация / логика / БД). cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-app printmanager-converter-server TCP-конвертер-сервер. Принимает запросы по TCP и передаёт их в app по HTTP. Проблемы с авторизацией по TCP. Выявить, приходит ли сообщение от конвертера. Выявить какой номер карты приходит от конвертера. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-converter-server printmanager-ftpd Временное хранилище для обмена файлами сканирования/копирования с принтерами. Проблема с заданием копирования (сканирование выполнялось, но документ не распечатался). Задание сканирования не появилось в ПринтМенеджер или нет его образа. Выявить ошибки при выполнении процесса обработки образа документа заданий сканирования и копирования. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-ftpd printmanager-db База данных ПринтМенеджера. Проверка запуска сервиса. Наличие ошибок запуска БД. Проверить наличие ошибок запуска БД. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-db printmanager-cups Контейнер сервера печати. Обрабатывает всю отложенную печать (клиентская, бесклиентская, через почту). Задания не распечатываются. Недоступна панель CUPS по порту 1631. Выявить ошибки работы сервиса. Выявить ошибки принтеров в CUPS. Примечание: Unable to encrypt connection: A TLS fatal alert has been received. — не является ошибкой системы. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-cups printmanager-redis Redis ПринтМенеджера. Брокер сообщений. Сингл: проверка запуска сервиса. Отказоустойчивая конфигурация: ноды ПринтМенеджера недоступны. Сингл: наличие ошибок запуска сервиса. Отказоустойчивая конфигурация: ошибки при переключении с master на slave. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-redis printmanager-redis-sentinel Redis Sentinel ПринтМенеджер. Существует только в схеме с балансировкой нагрузки. Ноды ПринтМенеджера недоступны. Выявить наличие ошибок при переключении с master на slave. cd /opt/printmanager docker-compose logs -f --tail=200 printmanager-redis-sentinel Агенты и Клиент ПМ Агенты и клиенты ПринтМенеджер не являются Docker-контейнерами. Логи доступны через системный журнал или файлы логов. Компонент Описание Когда анализировать (симптомы) Цель анализа Команда / расположение логов Сетевой агент Сканирование сети и сбор данных с сетевых устройств. Устройство не появляется в разделе «Инвентаризация — Устройства». Выявить ошибки запуска сервиса. Выявить ошибки опроса устройства. Выявить ошибки сканирования сети. cat /opt/printum-agent/agent.log Локальный агент Windows Мониторинг заданий печати на ОС Windows. Устройство не появляется в Личном кабинете. Не передаётся статистика по устройству. Выявить ошибки запуска сервиса. Выявить ошибки передачи данных. eventvwr → Журналы Windows → Приложение → источник ServicePrintum Локальный агент Linux Мониторинг заданий печати на ОС Linux. Устройство не появляется в Личном кабинете. Не передаётся статистика по устройству. Выявить ошибки запуска сервиса. Выявить ошибки передачи данных. sudo journalctl -u printum-jtm.service Клиент ПМ Windows Отправка заданий на печать на ОС Windows. Задание не появляется в очереди или не печатается на принтере для прямой печати. Принтеры не появляются на АРМ. Выявить ошибки запуска сервиса. Выявить ошибки передачи данных. eventvwr → Журналы Windows → Приложение → источник Print Manager Client Клиент ПМ Linux Отправка заданий на печать на ОС Linux. Задание не появляется в очереди или не печатается на принтере для прямой печати. Принтеры не появляются на АРМ. Выявить ошибки запуска сервиса. Выявить ошибки передачи данных. sudo journalctl -u printum-printmanager-client.service

Диагностика и сбор логов

Ошибка «Provided license key instead of activation key»

title: Ошибка «Provided license key instead of activation key» slug: ts-licenziya-provided-license-key tags: [лицензия, активация, токен, ошибка активации, license key] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг] related_pages:

kak-aktivirovat-ili-prodlit-licenziyu

Ошибка «Provided license key instead of activation key»

Симптомы

При попытке активировать лицензию в ЛК → Настройки → Общие → Организации система показывает ошибку:

Provided license key instead of activation key

Или в письме от ТП приходит ключ, но при вводе система его не принимает.

Причина

Перепутаны два разных значения:

Токен активации — генерируется в ЛК, отправляется в ТП. Выглядит как длинная строка Base64/JWT.
Лицензионный ключ — выдаётся ТП в ответ на токен. Вводится в поле «Указать лицензионный ключ».

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

Решение

Шаг 1. В ЛК → Настройки → Общие → Организации нажать «Токен активации» и скопировать актуальный токен именно этой системы.

Шаг 2. Отправить этот токен в ТП (support@printum.io) с названием организации.

Шаг 3. Полученный от ТП ключ ввести в поле «Указать лицензионный ключ» → «Сохранить».

Как проверить результат

В списке лицензий карточки организации отображаются типы лицензий, количество и срок действия.

Когда эскалировать

Ключ введён корректно (получен от ТП в ответ на токен этой системы), но ошибка сохраняется.
Система не позволяет открыть раздел «Организации».

Связанные страницы

Как активировать или продлить лицензию

Диагностика и сбор логов

Счётчики не обновляются после обновления Мониторинга

Симптомы

После обновления Мониторинга счётчики принтеров заморожены на дате обновления.
В Личном Кабинете → "Отчёты по устройствам" - дата последнего опроса не меняется.
Агент мониторинга работает, ошибок в админке Мониторинга нет.

Причина

Две наиболее частые:

Агент не перезапустился корректно после обновления — продолжает работать старая версия или агент завис.
Ошибка чтения данных в ClickHouse — при крупном обновлении (например, 4.1 → 4.3) формат хранения данных изменился, агент получает ошибку при записи или чтении.

Диагностика

Проверить статус контейнера агента:

sudo systemctl status printum-agent.service

Проверить логи агента в интерактивном режиме:

cd /opt/printum-agent/
tail agent.log -f

Признак проблемы 1 (агент завис):

# Ошибки по запуску периодических задач на опрос и сканирование:
level=error msg="get /agent/poll_tasks failed
level=error msg="get /agent/scan_tasks failed

Проверить работу периодической задачи по обработке регистров принтеров (periodic_update_register_of_printers_in_snmp):

cd /opt/printum/
sudo docker-compose logs -f --tail=5 worker-low

Признак проблемы 2 (ClickHouse):

[<date_time>: ERROR/ForkPoolWorker-26] Task apps.printer.tasks.periodic_update_register_of_printers_in_snmp[<UUID>] raised unexpected: ServerException('DB::Exception: Unknown codec family code: 0...

Решение

Агент не перезапустился

sudo systemctl restart printum-agent.service

Подождать 2–3 минуты, проверить счётчики в ЛК.

Ошибка ClickHouse

Не устраняется самостоятельно. Требует вмешательства на уровне БД.

Передать в ТП:

Логи агента системы Мониторинга.
Версию Мониторинга до и после обновления.
Вывод sudo docker-compose ps.

Как проверить результат

В ЛК → Отчёты по устройствам: дата последнего опроса обновилась.
Отправить тестовое задание на печать — счётчик вырос.

Когда эскалировать

В логах ошибка ClickHouse (Unknown codec family code или ServerException).
Агент запускается, но данные не поступают более 30 минут.

Связанные страницы

Диагностика и сбор логов

Скан не приходит на email

title: Скан не приходит на email slug: ts-skanirovanie-ne-prikhodit-na-email tags: [сканирование, email, SMTP, встроенное приложение, почта] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-skanirovaniya
ts-skanirovanie-bolshoy-fayl

Скан не приходит на email

Симптомы

Пользователь выполнил сканирование на email во встроенном приложении — операция завершилась без ошибок на экране МФУ.
Письмо со сканом не пришло.
Или кнопка отправки в приложении неактивна.

Диагностика

Шаг 1. Проверить SMTP-настройки ПринтМенеджера

Панель администратора ПринтМенеджера → Настройки → SMTP (или https://<ip_pm>:8080/config/constance/config/).

Отправить тестовое письмо. Если тестовое письмо не приходит — проблема в SMTP-настройках, а не в сканировании.

Типичные ошибки в логах при неверных SMTP-настройках:

Email message to <адрес> was not sent: authentication error

Шаг 2. Проверить email пользователя

Панель администратора Мониторинга → Пользователи → карточка пользователя → поле «Email».

Если email не заполнен — кнопка отправки в приложении будет неактивна.

Шаг 3. Проверить задание в ПринтМенеджере

Панель администратора ПринтМенеджера → Задания: найти задание сканирования. Если задания нет — файл не дошёл с МФУ до ПринтМенеджера (проблема в приложении или сети, а не в email).

Шаг 4. Проверить логи

cd /opt/printmanager
sudo docker-compose logs printmanager-app --tail=100 | grep -i "scan\|smtp\|email\|error"

Шаг 5. Проверить логи FTP-контейнера

cd /opt/printmanager
sudo docker-compose logs printmanager-ftpd --tail=100

Контейнер printmanager-ftpd отвечает за временное хранилище файлов сканирования. Ошибки здесь означают, что файл не был сохранён перед отправкой на email.

Шаг 6. Проверить правила пользователя

ЛК → Управление → Пользователи → правила. Правило «Запретить сканирование в почту» блокирует отправку.

Шаг 7. Проверить параметр сканирования на email другого сотрудника

Если сканирование выполняется на email другого сотрудника (Xerox, Sharp, Konica Minolta) — проверить, включён ли параметр SCAN_TO_ANOTHER_MAIL в https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования».

Решение

По результатам диагностики:

SMTP-настройки неверные → исправить в панели ПринтМенеджера, проверить тестовым письмом.
Email пользователя не заполнен → добавить в карточку, запустить синхронизацию Мониторинга и ПринтМенеджера.
Задания нет в ПринтМенеджере → диагностировать встроенное приложение.
Ошибки в логах FTP-контейнера → проверить доступность и работоспособность контейнера printmanager-ftpd.
Есть запрещающее правило → изменить правило.
Сканирование на email другого сотрудника не работает → включить SCAN_TO_ANOTHER_MAIL в настройках сканирования.

Как проверить результат

Выполнить сканирование на email тестового пользователя с корректно заполненным email. Письмо приходит в течение 1-2 минут.

Когда эскалировать

SMTP настроен корректно (тестовое письмо доходит), email пользователя заполнен, правил нет — скан не приходит.
В логах ошибки, которые не относятся к SMTP или правам.

Приложить: логи printmanager-app, настройки SMTP (без пароля), версии Мониторинга и ПринтМенеджера, вывод команды bash /opt/printmanager/logs.sh и версию cat /opt/printmanager/.version.

Связанные страницы

Диагностика и сбор логов

Скан не сохраняется в сетевую папку

title: Скан не сохраняется в сетевую папку slug: ts-skanirovanie-ne-sohranyaetsya-v-papku tags: [сканирование, SMB, сетевая папка, права доступа, путь] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-skanirovaniya

Скан не сохраняется в сетевую папку

Симптомы

Пользователь выполнил сканирование в папку — операция завершилась без ошибок на МФУ.
Файл в сетевой папке не появился.
Или кнопка «Сканировать в папку» в приложении неактивна.

Диагностика

Шаг 1. Проверить SMB-настройки в ПринтМенеджере

Панель администратора ПринтМенеджера → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования»:

SMB_HOSTNAME — hostname или IP сервера с папкой.
SMB_USERNAME — пользователь с правами записи в папку.
SMB_PASSWORD — пароль этого пользователя.

Если hostname не резолвится — попробовать заменить на IP-адрес.

Шаг 2. Проверить путь к папке пользователя

Панель администратора Мониторинга → Пользователи → карточка пользователя → поле «Путь к папке».

Если путь не заполнен — кнопка в приложении будет неактивна.

Путь указывается в формате \ИмяСервера\Папка или с шаблонными переменными. Поддерживаемые переменные:

$DEPARTMENT$ — отдел пользователя.
$USERNAME$ — имя пользователя.
$LOGIN$ — логин пользователя домена.

Пример: \ИмяСервера\$DEPARTMENT$\$USERNAME$.

Шаг 3. Проверить права доступа

Пользователь SMB_USERNAME должен иметь права на запись в папку пользователя. Проверить: попробовать записать файл в папку от имени SMB_USERNAME с другого компьютера.

Шаг 4. Проверить задание в ПринтМенеджере

Панель ПринтМенеджера → Задания: задание сканирования должно появиться. Если его нет — файл не дошёл с МФУ до ПринтМенеджера.

Шаг 5. Проверить логи

cd /opt/printmanager
sudo docker-compose logs printmanager-app --tail=100 | grep -i "scan\|smb\|error\|permission"

Шаг 6. Проверить правила

ЛК → Управление → Пользователи → правила. Правило «Запретить сканирование в папку» блокирует операцию.

Частые ситуации

Hostname SMB-сервера не резолвится с сервера ПринтМенеджера

Заменить SMB_HOSTNAME на IP-адрес в настройках ПринтМенеджера.

Ошибка прав доступа

В логах: Permission denied или Access denied.

Проверить: пользователь SMB_USERNAME должен иметь права на запись именно в ту папку, которая указана в карточке пользователя. Права на родительскую папку без прав на дочернюю — не работает.

Шифрование SMB несовместимо

Если включён SCAN_SMB_ENCRYPT, SMB-сервер должен поддерживать SMBv3 или выше. На старых серверах (Windows Server 2008, Samba старых версий) шифрование может не работать. Отключить SCAN_SMB_ENCRYPT для проверки.

Сканирование на папку другого сотрудника (Konica Minolta)

Проверить, включён ли параметр SCAN_TO_ANOTHER_SMB в Настройках сканирования ПринтМенеджера (https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования»).

Как проверить результат

Выполнить сканирование в папку тестового пользователя. Файл появляется в указанной сетевой папке в течение 1-2 минут.

Когда эскалировать

SMB-настройки верные, путь заполнен, права есть — файл не появляется.
В логах ошибки, не связанные с правами или hostname.

Приложить: логи printmanager-app, настройки SMB (без пароля), путь к папке пользователя, версии Мониторинга и ПринтМенеджера, вывод bash /opt/printmanager/logs.sh и версию cat /opt/printmanager/.version.

Связанные страницы

Сканирование — диагностика проблем

Диагностика и сбор логов

Белый экран или приложение не открывается на МФУ

title: Белый экран или приложение не открывается на МФУ slug: ts-vstroennoe-prilozhenie-belyy-ekran tags: [встроенное приложение, белый экран, не открывается, авторизация, Pantum, Kyocera, Ricoh] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер] related_pages:

kak-diagnostirovat-problemy-vstroennogo-prilozheniya
ts-vstroennoe-prilozhenie-ne-ustanavlivaetsya

Белый экран или приложение не открывается на МФУ

Симптомы

После нажатия иконки приложения на панели МФУ — белый экран или пустой экран без интерфейса.
Приложение открывается, но экран авторизации не появляется.
После ввода PIN-кода — белый экран вместо списка заданий.

Причины и решения

МФУ не может подключиться к серверу ПринтМенеджер

Белый экран — наиболее частый признак того, что приложение не получает ответ от ПринтМенеджер.

Проверить сетевой доступ МФУ к ПринтМенеджер:

МФУ должен иметь доступ к серверу ПринтМенеджер по порту 8080 (или 1631 для CUPS).
Проверить с рабочего места в той же подсети: curl -k https://<ip_пм>:8080/.

Проверить статус контейнеров ПринтМенеджер:

cd /opt/printmanager
sudo docker-compose ps

Все контейнеры должны быть Up.

Несовместимая версия прошивки

На некоторых моделях (особенно Pantum) после обновления прошивки приложение перестаёт открываться. Или, наоборот, устаревшая прошивка несовместима с текущей версией приложения.

Решение: запросить у ТП совместимую версию прошивки для конкретной модели. Обновить или откатить прошивку.

Приложение не переустановлено после смены прошивки

После обновления прошивки МФУ встроенное приложение необходимо переустановить.

Решение:

ЛК → «Удалить приложение».
Перезагрузить МФУ.
Установить приложение заново.

Конфликт со сторонним ПО на МФУ (Ricoh)

На Ricoh белый экран при авторизации по PIN-коду может быть вызван сторонними приложениями, установленными на МФУ (например, Device Software Manager).

Решение:

Открыть веб-интерфейс МФУ → раздел установленных приложений.
Удалить сторонние приложения, не связанные с Printum.
Перезагрузить МФУ.

Как проверить результат

После перезагрузки МФУ открыть приложение — экран авторизации отображается корректно. Авторизация по PIN или карте выполняется успешно.

Когда эскалировать

МФУ доступен по сети, контейнеры ПринтМенеджер работают, прошивка совместимая — белый экран сохраняется.
Проблема воспроизводится только на одной модели МФУ.

Приложить к заявке: вендор, модель, версия прошивки, версии М и ПринтМенеджер, версия приложения, логи printmanager-app и printmanager-converter-server.

Связанные страницы

SSL — self signed certificate in certificate chain

title: SSL — self signed certificate in certificate chain slug: ts-ssl-self-signed-in-chain tags: [ssl, self signed, сертификат, цепочка, CA] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг, ПринтМенеджер] related_pages:

trebovaniya-k-ssl-sertifikatam related_errors:
"[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:"

SSL — self signed certificate in certificate chain

Симптомы

В логах ПринтМенеджер при синхронизации с М:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
self signed certificate in certificate chain

Синхронизация Мониторинг–ПринтМенеджер не работает.

Причина

В файл server.crt включено содержимое корневого сертификата (CA). Это нарушает структуру цепочки доверия — корневой сертификат должен быть отдельным файлом (ca.crt), а не частью серверного сертификата.

Диагностика

Проверить, сколько сертификатов содержится в файле server.crt:

grep -c "BEGIN CERTIFICATE" /path/to/server.crt

Норма: 1 (серверный сертификат) или 2 (серверный + промежуточный CA). Ошибка: 3 и более — скорее всего, включён корневой сертификат.

Решение

Разделить сертификаты:

server.crt — только серверный сертификат (и промежуточный CA, если есть).
ca.crt — только корневой сертификат.

Переустановить с корректно разделёнными файлами:

sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \
  sudo -E SSL_CERT=/path/server.crt \
       SSL_KEY=/path/server.key \
       SSL_CERT_CA=/path/ca.crt bash -s agent

Как проверить результат

cd /opt/printmanager
sudo docker-compose logs printmanager-celery-print-queue --tail=50 | grep -i ssl

Ошибок SSL нет. Синхронизация завершается успешно.

Когда эскалировать

Структура сертификатов исправлена, но ошибка сохраняется.
Неизвестно, какой сертификат является корневым — потребуется помощь владельца PKI.

Связанные страницы

Требования к SSL-сертификатам для Printum

Проблемы сканирования

Документ сканируется но не доставляется

Документ сканируется но не доставляется Симптомы МФУ сообщает об успешном сканировании, но документ не приходит на почту и не появляется в папке. В журнале заданий задание отображается, но статус «Ошибка». Документ доходит с задержкой (более 5–10 минут). Возможные причины Сетевая недоступность SMTP-сервера или SMB-хоста с сервера ПринтМенеджер. Документ превысил ограничения SMTP по размеру (не настроена обработка больших документов). Задание застряло в очереди обработки ПринтМенеджер (проблема с контейнером). Неверный e-mail или путь к папке в профиле пользователя. Диагностика Найти задание в журнале: Управление → Задания → фильтр по пользователю и дате. Проверить статус задания и наличие ошибки. Проверить логи ПринтМенеджер: docker-compose logs --tail=300 | grep -i scan Проверить сетевую доступность SMTP и SMB с сервера ПринтМенеджер: SMTP: telnet SMB: попробовать монтирование папки вручную Проверить настройку обработки больших документов: SCAN_LARGE_DOC_PROCESS_METHOD, SCAN_MAX_SIZE. Логи и диагностические данные Где смотреть логи printmanager-app — Основной контейнер ПринтМенеджер — обработка и доставка документа после сканирования cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app printmanager-ftpd — FTP-сервер — временное хранилище для обмена файлами сканирования и копирования cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-ftpd Что искать в логах Выявить ошибки при выполнении процесса обработки образа документа задания сканирования и копирования. Выявить ошибки доставки файла после сканирования. Проверить, поступил ли образ документа в FTP-хранилище. Что приложить к обращению в поддержку Вывод команды bash /opt/printmanager/logs.sh Версию: cat /opt/printmanager/.version Описание сценария и шагов воспроизведения ОС сервера Решение Убедиться в сетевой доступности SMTP/SMB с сервера ПринтМенеджер. Настроить обработку больших документов (SCAN_LARGE_DOC_PROCESS_METHOD): выбрать «Отправить ссылку», «Сетевую папку» или «Разделить». Настроить максимальный размер в SCAN_MAX_SIZE на 20–25% меньше лимита почтового сервера. Перезапустить контейнеры при застревании заданий: cd /opt/printmanager && docker-compose restart Что проверить перед эскалацией Версию ПринтМенеджера Логи контейнера printmanager-app (grep scan) Сетевую доступность SMTP и SMB с сервера Размер сканируемого документа и лимиты SMTP Статус задания в журнале Связанные страницы Сканирование на email не работает Сканирование в сетевую папку не работает Настройка отправки документов большого размера

SSL — unable to get local issuer certificate (отсутствует SAN)

title: SSL — unable to get local issuer certificate (отсутствует SAN) slug: ts-ssl-unable-to-get-local-issuer tags: [ssl, unable to get local issuer, SAN, subject alternative name, сертификат] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Мониторинг, ПринтМенеджер] related_pages:

trebovaniya-k-ssl-sertifikatam related_errors:
"[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:"

SSL — unable to get local issuer certificate (отсутствует SAN)

Симптомы

В логах при синхронизации Мониторинг–ПринтМенеджер или подключении компонентов:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
unable to get local issuer certificate

Причина

В SSL-сертификате сервера отсутствует поле Subject Alternative Name (SAN). Современные клиенты (Python 3.7+, браузеры) требуют наличия SAN — поле CN (Common Name) уже недостаточно.

Диагностика

Проверить, есть ли SAN в сертификате сервера:

openssl x509 -in /path/to/server.crt -noout -ext subjectAltName

Норма: вывод содержит DNS: или IP: записи. Ошибка: пустой вывод или No extensions in certificate — SAN отсутствует.

Решение

Перевыпустить сертификат с полем SAN. В SAN указать все адреса сервера:

DNS:server.example.com
DNS:server
IP:10.0.0.1

После перевыпуска переустановить с новым сертификатом:

sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \
  sudo -E SSL_CERT=/path/server.crt \
       SSL_KEY=/path/server.key \
       SSL_CERT_CA=/path/ca.crt bash -s agent

Если нет возможности перевыпустить сертификат — перейти на автоматические сертификаты (установка без SSL-параметров). Автоматические сертификаты содержат SAN и не вызывают этой ошибки.

Как проверить результат

openssl s_client -connect <адрес>:<порт> </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Вывод содержит SAN с актуальными адресами сервера. Синхронизация завершается без ошибок.

Когда эскалировать

PKI управляется заказчиком — перевыпуск сертификата требует его участия.
После перевыпуска с SAN ошибка сохраняется.

Связанные страницы

Требования к SSL-сертификатам для Printum

BrokenPipeError — задания не передаются из CUPS в ПМ (Linux)

title: BrokenPipeError — задания не передаются из CUPS в ПринтМенеджер (Linux) slug: ts-brokenpipe-klient-pm-linux tags: [BrokenPipeError, клиент ПМ, Linux, CUPS, Astra, задания] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [Клиент ПМ, CUPS, ПринтМенеджер] related_pages:

kak-ustanovit-klient-pm-na-linux
kak-diagnostirovat-problemy-pechati-po-etapam-puti-zadaniya related_errors:
"Broken pipe"
"BrokenPipeError"

BrokenPipeError — задания не передаются из CUPS в ПринтМенеджер (Linux)

Симптомы

Пользователь отправил задание на печать — в CUPS статус Job completed.
В очереди ПринтМенеджер и на МФУ задания нет.
Служба клиента ПМ запущена (active (running)).
В логах клиента ПМ:

BrokenPipeError: [Errno 32] Broken pipe

Причина

Клиент ПМ считывает задание из CUPS, но соединение обрывается до того, как задание передано в ПринтМенеджер. Типичные причины:

Несовместимость ОС — после обновления Astra Linux (например, 1.7.7 → 1.7.9) изменилась версия Python или системных библиотек, с которыми работает клиент.
Конфликт с CUPS — на АРМ установлен конкурирующий сервис печати (PrintXpert, SafeQ и др.).
Ошибка конфигурации CUPS — клиент подключается к CUPS по неверному адресу или порту.

Диагностика

Шаг 1. Проверить логи клиента ПМ:

sudo journalctl -u printum-printmanager-client.service --since "1 hour ago" | grep -i "broken\|error\|pipe"

Зафиксировать полный текст ошибки — строки до и после BrokenPipeError.

Шаг 2. Проверить версию ОС:

cat /etc/os-release

Шаг 3. Проверить наличие конкурирующих сервисов печати:

systemctl list-units | grep -i "print\|cups\|spool"

Если есть активные сервисы кроме cups и printum-printmanager-client — вероятен конфликт.

Шаг 4. Проверить доступность CUPS:

lpstat -r

Норма: scheduler is running.

Решение

Переустановка клиента ПМ (первый шаг)

Переустановка не меняет настройки — settings.yml сохраняется.

# Остановить службу
sudo systemctl stop printum-printmanager-client.service

# Переустановить по инструкции из Руководства администратора
# (ссылку на дистрибутив запросить в ТП)

# Проверить статус после установки
sudo systemctl status printum-printmanager-client.service

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

Деактивировать конкурирующий сервис:

sudo systemctl stop <имя_сервиса>
sudo systemctl disable <имя_сервиса>

После этого перезапустить клиент ПМ и проверить передачу заданий.

После обновления ОС

Переустановка клиента ПМ с актуальным дистрибутивом решает проблему несовместимости. Если не помогло — эскалировать в ТП с логами и версией ОС.

Как проверить результат

sudo journalctl -u printum-printmanager-client.service --since "5 minutes ago"

Ошибок BrokenPipeError нет. Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджер.

Когда эскалировать

Переустановка не помогла.
ОС обновлялась перед появлением проблемы.
Конкурирующих сервисов нет, но ошибка сохраняется.

Приложить к заявке: вывод journalctl с ошибкой, версию ОС (cat /etc/os-release), версию клиента ПМ, версию ПринтМенеджер.

Связанные страницы

Встроенное приложение — диагностика проблем

title: Встроенное приложение — диагностика проблем slug: kak-diagnostirovat-problemy-vstroennogo-prilozheniya tags: [встроенное приложение, Встроенное приложение, диагностика, МФУ, Kyocera, Xerox, Ricoh, Lexmark, Pantum] domain: Troubleshooting type: Runbook audience: partner-engineer product_versions: "4.x" status: ready related_components: [Встроенное приложение, ПринтМенеджер, Мониторинг] related_pages:

ts-vstroennoe-prilozhenie-ne-ustanavlivaetsya
ts-vstroennoe-prilozhenie-belyy-ekran
ts-zadaniya-ne-otobrazhaetsya-v-prilozhenii
ts-avtorizaciya-po-karte-ne-rabotaet-v-prilozhenii
ts-ricoh-postoyannyy-zapros-tokena
kak-rabotaet-avtorizaciya-na-mfu

Встроенное приложение — диагностика проблем

Как устанавливается приложение

Автоматическая установка из ЛК (кнопка «Установить приложение»):

Xerox, Konica Minolta, HP, Sharp, Ricoh

Ручная установка через интерфейс МФУ с токеном:

Kyocera, Lexmark, Pantum, Canon и другие

Для получения инструкций по конкретному вендору и модели — запрос в ТП: support@printum.io

Предусловия для работы приложения

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

Устройство добавлено в Мониторинг и опрашивается (статус не серый).
У устройства есть лицензия M (мониторинг) + PM (управление печатью) + EMB (встроенное приложение).
Синхронизация Мониторинг–ПринтМенеджер выполнена (ЛК → Настройки → Интеграции → ПринтМенеджер).
МФУ доступен по сети с сервера ПринтМенеджер (проверить ping <ip_мфу> с сервера).
Версия прошивки МФУ соответствует требованиям (запросить у ТП список совместимых прошивок).

Алгоритм диагностики

Шаг 1. Проверить лицензии

ЛК → Управление → Устройства → развернуть карточку → вкладка «Лицензии».

Должны быть активны: M, PM, EMB. Если EMB отсутствует — нажать «Установить приложение» или «Сгенерировать токен».

Шаг 2. Проверить синхронизацию

Если приложение установлено, но настройки (пользователи, правила, PIN-коды) не применяются — запустить синхронизацию Мониторинг–ПринтМенеджер вручную.

Шаг 3. Проверить логи ПринтМенеджер

cd /opt/printmanager
sudo docker-compose logs printmanager-app --tail=100 | grep -i "error\|embed\|auth"
sudo docker-compose logs printmanager-converter-server --tail=100

Шаг 4. Проверить доступность ПринтМенеджер с устройства

МФУ должен иметь сетевой доступ к серверу ПринтМенеджер. Проверить с сервера ПринтМенеджер:

ping <ip_мфу>
curl -k https://<ip_мфу>/

Если МФУ недоступен с сервера ПринтМенеджер — сетевая проблема, решается на стороне заказчика.

Шаг 5. Переустановить приложение

Если предыдущие шаги не дали результата:

В ЛК → Управление → Устройства → «Удалить приложение» (или «Удалить токен»).
Перезагрузить МФУ.
Установить заново.

Навигация по конкретным проблемам

Симптом	Статья
Приложение не устанавливается, ошибка при установке	Встроенное приложение не устанавливается
Белый экран или приложение не открывается	Белый экран во встроенном приложении
Пользователь авторизовался, но заданий нет	Задания не отображаются в приложении
Авторизация по карте не работает	Авторизация по карте не работает во встроенном приложении
Ricoh: приложение постоянно запрашивает токен	Ricoh — постоянный запрос токена
Xerox: сканирование/копирование не работает без ошибок	Xerox — сканирование не работает, ошибок нет

Что приложить при эскалации в ТП

Вендор и модель МФУ, версия прошивки.
Версия приложения (есть в ЛК или в интерфейсе МФУ).
Версии М и ПринтМенеджер.
Логи printmanager-app и printmanager-converter-server.
Описание симптома: что именно происходит на экране МФУ.

Контейнеры Unhealthy после обновления в конфигурации с балансировщиком

title: Контейнеры Unhealthy после обновления в конфигурации с балансировщиком slug: ts-konteinery-unhealthy-posle-obnovleniya tags: [обновление, unhealthy, балансировщик, HAProxy, NFS, Redis, docker] domain: Troubleshooting type: Troubleshooting audience: partner-engineer product_versions: "4.x" status: ready related_components: [ПринтМенеджер, Балансировщик, NFS, Redis] related_pages:

kak-obnovit-printum
kak-rabotaet-otkazoustoychivyy-printmanager
kak-rabotaet-filialnaya-arhitektura-printum related_errors:
"connection refused"

Контейнеры Unhealthy после обновления в конфигурации с балансировщиком

Симптомы

После обновления ПринтМенеджер в схеме с балансировщиком:

Один или несколько контейнеров printmanager-app запускаются со статусом unhealthy.
Нода недоступна через HAProxy (статус DOWN в панели HAProxy).
Печать работает частично или не работает совсем.

Причина

Три наиболее частые:

NFS не смонтирован — volume printmanager_media недоступен, контейнер не может запуститься.
Redis потерял master — после одновременного перезапуска нод Redis sentinel не успел выбрать нового мастера.
Ошибка прав в printmanager-ftpd — контейнер завершился с ошибкой при записи PID-файла.

Диагностика

Шаг 1. Проверить статус всех контейнеров на проблемной ноде:

cd /opt/printmanager
sudo docker-compose ps

Зафиксировать какие контейнеры в статусе unhealthy или Exit.

Шаг 2. Проверить монтирование NFS:

df -h | grep printmanager
mount | grep nfs

Норма: NFS-том смонтирован и отображается в выводе. Ошибка: том отсутствует или connection refused.

Шаг 3. Проверить логи printmanager-app:

sudo docker-compose logs printmanager-app --tail=100

Признак NFS-проблемы:

failed to mount local volume: connection refused, port=2049, addr=127.0.0.1

Шаг 4. Проверить Redis:

sudo docker-compose logs printmanager-redis --tail=50

Признак проблемы Redis:

Connection with master lost
MASTER <-> REPLICA sync started
+sdown master
+tilt mode entered

Шаг 5. Проверить printmanager-ftpd:

sudo docker-compose logs printmanager-ftpd --tail=50

Признак проблемы ftpd:

Permission denied при записи PID

Решение

NFS не смонтирован

Проверить, запущен ли stunnel (если NFS проброшен через stunnel):

systemctl status stunnel

Если stunnel не запущен:

systemctl start stunnel

После этого перезапустить ПринтМенеджер:

sudo docker-compose down && sudo docker-compose up -d

Если stunnel отсутствует после восстановления из бэкапа — см. restore.sh не восстанавливает stunnel (TODO).

Redis не выбрал мастера

Подождать 1–2 минуты — sentinel должен автоматически выбрать нового мастера. Если не восстановился:

sudo docker-compose restart printmanager-redis printmanager-redis-sentinel

Проверить логи через 1 минуту:

sudo docker-compose logs printmanager-redis-sentinel --tail=30

Норма: +elected-leader, +promoted-slave.

Ошибка прав в printmanager-ftpd

sudo docker-compose restart printmanager-ftpd

Если ошибка повторяется — передать логи в ТП.

Как проверить результат

sudo docker-compose ps

Все контейнеры в статусе Up. В панели HAProxy нода отображается как UP. Тестовое задание успешно печатается.

Когда эскалировать

Причина не определяется по логам.
NFS недоступен по сетевым причинам (не связано с stunnel).
Redis не восстанавливается после перезапуска.
Проблема воспроизводится на всех нодах одновременно.

Приложить к заявке: вывод docker-compose ps со всех нод, логи printmanager-app, printmanager-redis, printmanager-ftpd, версии М и ПринтМенеджер.

Связанные страницы

Ошибка MultipleObjectsReturned при обновлении ПМ 4.3 → 4.4

Симптомы

Обновление ПринтМенеджер с 4.3 на 4.4 завершается ошибкой таймаута:

Waiting for the server to start
......................................................................................................................................................
Timeout error. Check docker logs. Then restart the installation.

В логах ПринтМенеджера:

__fake__.RuleAction.MultipleObjectsReturned: get() returned more than one RuleAction -- it returned 2!

Система не обновляется, приходиться откатывать в предыдущее состояние.

Причина

В таблице print_rules_ruleaction БД ПринтМенеджера есть дублирующиеся записи с одинаковым action_type. При миграции на 4.4 скрипт ожидает одну запись — получает две, падает.

Дубли появляются при обновлении с версий 4.2 и ниже. На чистых установках 4.3 не воспроизводится.

Диагностика

Проверить наличие дублирующихся записей в:

В панели администратора Мониторинга → Правила → Действия / Правила → Условия
В панели администратора ПринтМенеджера → Правила → Действия / Правила → Условия

Признак: существуют дубли одних и тех же записей.

Решение

Самостоятельно не устраняется. Требует удаления дублей из БД ПринтМенеджер вручную.

Передать в ТП:

Версии Мониторинга и ПринтМенеджера до обновления.
Логи установки (install.log на сервере ПринтМенеджер).
Логи системы ПринтМенеджера после обновления.
Подтверждение, что система обновлялась с версий 4.2 или ниже.

ТП предоставит команды для удаления дублей из таблицы print_rules_ruleaction. После этого обновление повторяется стандартным способом.

Как проверить результат

Обновление завершается без ошибок таймаута. В панели администратора ПринтМенеджер отображается версия 4.4.x. Правила печати работают корректно.

Когда эскалировать

Сразу — проблема не устраняется без вмешательства в БД.

Связанные страницы

Как обновить Printum

Синхронизация М–ПМ завершается ошибкой 403 после обновления

Симптомы

В различных системных отчетах ПринтМенеджера https://<address_pm>:8080/config/web/reports после обновления:

Bad response from monitoring 403 with error: <Response [403]>

Принтеры не синхронизируются из Мониторинга в ПринтМенеджер. Задания на МФУ не приходят.

Причина

После обновления Мониторинга или ПринтМенеджер значение MONITORING_KEY перестало совпадать между компонентами. Это происходит если при обновлении ключ был пересоздан или не перенесён корректно.

Решение

В панели администратора Мониторинга → Принтменеджеры → Принтменеджеры: вписать новое значение в поле Кодовый ключ, установите чек-бокс Валидация и сохраните.
В панели администратора ПринтМенеджер → Настройки → Настройки синхронизации с Мониторингом: вставить тот же ключ в поле MONITORING_KEY, сохранить.
Запустить синхронизацию вручную: панель администратора Мониторинга → Принтменеджеры → Принтменеджеры → «Синхронизировать сейчас».

Как проверить результат

Синхронизация завершается без ошибок. В различных системных отчетах ПринМенеджера нет 403. Принтеры из Мониторинга появились в панели ПринтМенеджера.

Когда эскалировать

Ключи совпадают, но ошибка 403 сохраняется.
Нет доступа к панели администратора ПринтМенеджер.

Приложить к заявке: версии Мониторинга и ПринтМенеджер и логи обоих системы.