Question

6

lpr not working - scheduler not responding

rated 0 times [ 6] [ 0] / answers: 1 / hits: 13570 / 2 Years ago, fri, june 10, 2022, 7:01:12

I'm running Ubuntu 13.04 on my computer at work, which has networked printers. I have previously been able to print using the lpr command, but recently this has stopped working.

$ lpr test

lpr: Error - scheduler not responding.



$ lpstat -t

scheduler is running

no system default destination

lpstat: Bad Request

lpstat: Bad Request

lpstat: Bad Request

lpstat: Bad Request

lpstat: Bad Request



$ ps aux | grep cups

root      1153  0.0  0.1  73500  3552 ?        Ss   Sep08   0:01 /usr/sbin/cupsd -F

root      1212  0.0  0.0  70428  1464 ?        Ss   Sep08   0:00 /usr/sbin/cups-browsed

I also don't see any printers if I enter the print dialog from a program; I can only print to a pdf.

Does anyone know what's gone wrong? What config files do you need to see?

edit: I'm adding some additional information.

I'm using a remote print server, and my ~/.cups/client.conf contains only this line:

ServerName print1.eecis.udel.edu

I tried removing the cups package and installing it again, and noticed during the installation the line

"lpinfo: Bad Request" appeared.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

beateyra

Add To Favorites

Follow

Total Points: 499

Total Questions: 113

Total Answers: 125

Location: Falkland Islands

Member since Mon, Jul 13, 2020

4 Years ago

answered 2 Years ago izeeas · Accepted Answer

The Arch Bugtracker knows about this bug/regression which is introduced in the 1.6 cups version:

The default IPP version for requests is now 2.0 (STR #3929)

And most likely your cups server has an older cups version which still defaults to the older IPP version. The workaround from the ARCH wiki:

Using a CUPS 1.6.x client with a <= 1.5.x server

As of CUPS version 1.6, the client defaults to IPP 2.0. If the server uses CUPS <= 1.5 / IPP <= 1.1, the client doesn't downgrade the protocol automatically and thus can't communicate with the server. A workaround (undocumented as of 2013-05-07, but see this bug report) is to put the following in /etc/cups/client.conf:

ServerName HOSTNAME-OR-IP-ADDRESS[:PORT]/version=1.1