Bug 60380

Summary:

Бесконечная подготовка к печати у Pantum CM1100ADW при подключении по wi-fi через backend error handler

Product:

Sisyphus

Reporter:

Белая Алёна <belayaav>

Component:

cups

Assignee:

Anton Farygin <rider>

Status:

NEW ---

QA Contact:

qa-sisyphus

Severity:

normal

Priority:

CC:

george, rider

Version:

unstable

Hardware:

x86_64

OS:

Linux

Attachments:

Description	Flags
logs_beh	none

Description

Белая Алёна 2026-09-03 12:38:44 MSK

cups-2.4.19-alt1
cups-filters-2.0.1-alt2
libcupsfilters-2.2.1-alt3

Стенды: 
Alt Workstation 11.2 x86_64, обновленный до Sisyphus
Alt Education 11.2 KDE x86_64, обновленный до Sisyphus
Alt Education 11.2 XFCE x86_64, обновленный до Sisyphus

Проверялось на реальном оборудовании:
Ноутбук F+ Flaptop FLTP-5i5-16512-W
МФУ Pantum CM1100ADW

Шаги воспроизведения:
1. Подключить принтер и ноутбук к одной и той же wi-fi сети для возможности подключения к принтеру по wi-fi
2. В браузере открыть cups: http://localhost:631/admin
3. В cups перейти во вкладку Администрирование > Добавить принтер > Выбрать "Backend Error Handler" > Продолжить > Подключение: beh:/1/0/60/socket://XX.XX.XX.XX* > Продолжить >  Написать название принтера > указать драйвер > Добавить принтер
* здесь socket://XX.XX.XX.XX - это то, как отображается протокол подключения по wi-fi в выводе команды lpinfo -v. IP МФУ в сети можно посмотреть на самом МФУ
4. В cups выбрать Принтеры > Выбрать принтер > Печать пробной страницы

Результат: на экране МФУ появляется надпись "Печать" и прогресс-бар, но печать не осуществляется, остается висеть в таком состоянии. Если с ноутбука отменить задание, на МФУ статус не меняется, он продолжает показывать надпись "Печать". Если нажать кнопку "Отмена" на самом МФУ, то появляется надпись "Отмена" с тем же прогресс-баром, которая так же продолжает висеть продолжительное время. 

Ожидаемый результат: успешная печать пробной страницы. 

Если этот же МФУ подключить по USB и добавить через backend error handler, то печать осуществляется успешно, не зависает. 
Подключение без backend error handler, т.е напрямую по wi-fi и eth проблем так же не вызвало. 
Дополнительно подключение по wi-fi через backend error handler проверялось с МФУ BM5100FDW и там печать осуществилась успешно.

Comment 1

Anton Farygin 2026-09-03 15:00:46 MSK

beh сам ничего не печатает, он лишь запускает socket backend с указанным URI и следит за кодом возврата. Раз напрямую через socket:// то же МФУ печатает, нужно понять, чем отличается сессия под beh. Для этого пришлите, пожалуйста:

1. /var/log/cups/error_log с включённым отладочным уровнем: в /etc/cups/cupsd.conf поставить LogLevel debug2, перезапустить cupsd (systemctl restart cups), очистить очередь, отправить пробную страницу, дождаться зависания, отменить задание с ноутбука и приложить лог целиком.
2. Вывод lpstat -v и содержимое /etc/cups/ppd/<имя_принтера>.ppd для очереди с beh.
3. Какой драйвер/PPD выбирали при добавлении очереди с beh и такой ли же был в очереди с прямым socket://, которая печатала успешно.
4. Для сравнения тот же error_log при печати напрямую через socket://IP (без beh), чтобы сопоставить.
5. Что после зависания показывает cupsd в статусе задания: lpstat -o и lpstat -p -l.

Comment 2

Белая Алёна 2026-09-04 18:46:50 MSK

Created attachment 22121 [details]
logs_beh

Собрала логи, которые вы просили. 
Сегодня даже в случае прямого подключения по wi-fi принтер зависает. Вчера точно работал. Однако error_log все же решила приложить для обоих случаев, возможно в них будет какая-то полезная информация.

Comment 3

Anton Farygin 2026-09-04 19:19:13 MSK

Спасибо за логи, но, к сожалению, в них нет самого главного. Оба error_log содержат только последние ~50 секунд: момент отмены задания. Старт задания, запуск фильтров и бэкенда, обмен с принтером в них не попали. Причина: при LogLevel debug2 лог заполняет 1 МБ за несколько секунд, и cupsd по умолчанию (MaxLogSize 1m) ротирует его, старая часть уходит в error_log.O и затирается при следующей ротации.

Из того, что видно, важное: очередь Beh_CM1100ADW создана с PPD "Pantum CM1100ADW Series, driverless, cups-filters" (в PPD: *cupsFilter2: "image/urf image/urf 0 -"), а device-uri у неё socket://10.88.144.151. То есть на порт 9100 принтеру уходит Apple Raster (URF), формат, который предназначен для отправки через IPP (ipp://, ipps://, dnssd://). По socket принтер ожидает свой язык (PCL/PS), и URF-поток на порту 9100 как раз даёт симптом "Печать" без результата и зависание. beh здесь ни при чём: он просто запускает тот же socket-бэкенд. Ваше замечание, что сегодня и прямое socket-подключение перестало печатать, это подтверждает.

Прошу перепроверить в двух корректных конфигурациях:

1. Driverless по IPP без TLS и без dnssd, чтобы исключить проблемы с сертификатом принтера:
   lpadmin -p cm1100 -E -v ipp://10.88.144.151/ipp/print -m everywhere
   lp -d cm1100 /usr/share/cups/data/testprint
   Если нужен именно beh: lpadmin -p cm1100beh -E -v beh:/1/0/60/ipp://10.88.144.151/ipp/print -m everywhere

2. Если нужно печатать именно через socket://, для этого требуется PPD/драйвер под язык принтера (у Pantum это собственный Linux-драйвер), driverless-PPD для socket не подходит.

И, пожалуйста, логи заново: в /etc/cups/cupsd.conf добавьте MaxLogSize 0 рядом с LogLevel debug2, systemctl restart cups, затем очистите очередь, отправьте задание, дождитесь зависания, отмените и приложите error_log целиком. Если в результате пункта 1 печать через ipp:// и через beh:/…/ipp:// проходит, баг закроем как ошибку конфигурации.