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 и там печать осуществилась успешно.
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.
Created attachment 22121 [details] logs_beh Собрала логи, которые вы просили. Сегодня даже в случае прямого подключения по wi-fi принтер зависает. Вчера точно работал. Однако error_log все же решила приложить для обоих случаев, возможно в них будет какая-то полезная информация.
Спасибо за логи, но, к сожалению, в них нет самого главного. Оба 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:// проходит, баг закроем как ошибку конфигурации.
Created attachment 22141 [details] beh logs through socket with drivers from vendor and "driverless" driver >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 Так добавить нельзя: > lpadmin: IPP Everywhere driver requires an IPP connection. Добавила с драйвером "Pantum CM1100ADW Series, driverless, cups-filters", отработало успешно При подключении через socket:// backend error handler не отработал и с драйвером от вендора. Error_log прилагаю для случаев, когда задание на печать отправлялось через beh с драйвером "Pantum CM1100ADW Series, driverless, cups-filters" - error_log_beh_socket.txt и когда задание на печать отправлялось через beh с драйвером от вендора (https://www.pantum.ru/wp-content/uploads/2024/06/pantum-1_1_99-alt3_x86_64-12.zip) - error_log_beh_driver.txt Итог: через ipp:// и beh:/../ipp:// печать проходит, через beh:/.../socket:// не проходит в том числе с драйверами от вендора
Спасибо, теперь логи полные. Разбор: 1. beh:/1/0/60/ipp://… с PPD "driverless, cups-filters" печатает, ipp:// напрямую печатает. То есть beh как таковой работает, а принтер по IPP исправен. 2. beh:/…/socket:// с driverless-PPD (error_log_beh_socket.txt, задание 18): socket-бэкенд подключился к порту 9100, отправил ~90 КБ Apple Raster, после чего принтер перестал читать данные и завис до отмены задания через полторы минуты. Это ожидаемо: на порт 9100 принтер ждёт свой язык (PCL/PS), а не URF. Такая конфигурация неработоспособна независимо от beh, см. #60382. 3. beh:/…/socket:// с драйвером от Pantum (error_log_beh_driver.txt, задание 21): до сетевого соединения дело вообще не дошло. beh перед запуском настоящего бэкенда полностью читает задание во временный файл, а фильтр вендора ptps за три минуты не выдал ни байта и не завершился. Единственное его сообщение: getsysteminfo: "Debian GNU/Linux 11 (bullseye)". Зависает именно фильтр вендора, а не beh и не socket. Чтобы понять, виноват ли ptps сам по себе или он не переваривает DEVICE_URI вида beh:/…, нужен один контрольный тест: та же очередь с драйвером Pantum, но напрямую socket://10.88.144.151, без beh. Если так печатает, значит фильтр Pantum разбирает DEVICE_URI и спотыкается о схему beh, это вопрос к Pantum. Если не печатает и так, фильтр вендора не работает на этой системе (он собран под Debian 11), и это тоже не к cups. Отдельно: отказ lpadmin для beh:/…/ipp:// с -m everywhere ("IPP Everywhere driver requires an IPP connection") это ограничение cupsd, он смотрит на схему URI и не заглядывает внутрь beh. Обход у вас уже есть: PPD "driverless, cups-filters" с beh работает.
> Чтобы понять, виноват ли ptps сам по себе или он не переваривает DEVICE_URI вида beh:/…, нужен один контрольный тест: та же очередь с драйвером Pantum, но напрямую socket://10.88.144.151, без beh. Если так печатает, значит фильтр Pantum разбирает DEVICE_URI и спотыкается о схему beh, это вопрос к Pantum. Если не печатает и так, фильтр вендора не работает на этой системе (он собран под Debian 11), и это тоже не к cups. Как я понимаю, каким бы ни был результат контрольного теста, это в любом случае проблема на стороне устройства/проприетарного драйвера, а не cups. Соответственно, исправлений со стороны cups не будет. В такое случае, предлагаю закрыть баг как Wontfix. Если нужно дополнить баг логами ошибки проприетарного драйвера/устройства - прошу указать, я дополню.
будет будет.
cups-2.4.19-alt2 -> sisyphus: Tue Sep 08 2026 Anton Farygin <rider@altlinux> 2.4.19-alt2 - Web UI: hide cups-filters driverless PPDs for socket/lpd device URIs, such queues cannot print (Closes: #60382) - Allow the everywhere driver and show driverless PPDs for beh-wrapped IPP device URIs (Closes: #60380)
