[arch-general] update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled
Guys, Cups 1.5.2 update caused all user submitted jobs to stick in que and not print. However, if I use the web interface and print a test page or print a test page from kde print manager - everything works. I have been through the cupsd.conf page a cups.org and though my config and I can't find any reason jobs would just stop printing. Is anyone else having problems submitting jobs to a network cups server. With LogLevel set to debug, I get the following in error_log: D [10/Feb/2012:13:58:14 -0600] cupsdAcceptClient: 17 from 192.168.6.102:631 (IPv4) D [10/Feb/2012:13:58:14 -0600] cupsdReadClient: 17 GET /printers/LaserJet.ppd HTTP/1.1 D [10/Feb/2012:13:58:14 -0600] cupsdSetBusyState: newbusy="Active clients and printing jobs", busy="Printing jobs" D [10/Feb/2012:13:58:14 -0600] cupsdAuthorize: No authentication data provided. D [10/Feb/2012:13:58:14 -0600] cupsdSetBusyState: newbusy="Printing jobs", busy="Active clients and printing jobs" D [10/Feb/2012:13:58:14 -0600] cupsdReadClient: 17 WAITING Closing on EOF D [10/Feb/2012:13:58:14 -0600] cupsdCloseClient: 17 D [10/Feb/2012:13:58:14 -0600] cupsdSetBusyState: newbusy="Printing jobs", busy="Printing jobs" D [10/Feb/2012:13:58:15 -0600] cupsdReadClient: 15 POST /printers/LaserJet HTTP/1.1 D [10/Feb/2012:13:58:15 -0600] cupsdSetBusyState: newbusy="Active clients and printing jobs", busy="Printing jobs" D [10/Feb/2012:13:58:15 -0600] cupsdAuthorize: No authentication data provided. D [10/Feb/2012:13:58:15 -0600] cupsdReadClient: 15 1.1 Get-Job-Attributes 1 D [10/Feb/2012:13:58:15 -0600] Get-Job-Attributes ipp://192.168.6.17:631/printers/LaserJet D [10/Feb/2012:13:58:15 -0600] Returning IPP successful-ok for Get-Job-Attributes (ipp://192.168.6.17:631/printers/LaserJet) from 192.168.6.102 D [10/Feb/2012:13:58:15 -0600] cupsdSetBusyState: newbusy="Printing jobs", busy="Active clients and printing jobs" D [10/Feb/2012:13:58:15 -0600] cupsdReadClient: 15 POST /printers/LaserJet HTTP/1.1 D [10/Feb/2012:13:58:15 -0600] cupsdSetBusyState: newbusy="Active clients and printing jobs", busy="Printing jobs" D [10/Feb/2012:13:58:15 -0600] cupsdAuthorize: No authentication data provided. D [10/Feb/2012:13:58:15 -0600] cupsdReadClient: 15 1.1 Get-Printer-Attributes 1 D [10/Feb/2012:13:58:15 -0600] Get-Printer-Attributes ipp://192.168.6.17:631/printers/LaserJet D [10/Feb/2012:13:58:15 -0600] Returning IPP successful-ok for Get-Printer-Attributes (ipp://192.168.6.17:631/printers/LaserJet) from 192.168.6.102 D [10/Feb/2012:13:58:15 -0600] cupsdSetBusyState: newbusy="Printing jobs", busy="Active clients and printing jobs" Does this indicate an error to anyone familiar with cups output? Something changed, but what? -- David C. Rankin, J.D.,P.E.
On 02/10/2012 02:05 PM, David C. Rankin wrote:
Guys,
Cups 1.5.2 update caused all user submitted jobs to stick in que and not print.
I'm not convinced this is cups. I just downgraded to 1.5.0 and I still get the same behavior and I was printing before this last set of updated. Here is another bit of information. When the user submits the job, it shows up on the cups 'jobs' list on the server. It just sits there. If I cancel the job on the server, then the client computer job also clears. So the jobs are getting from the client to the server and the client-server can communicate fine, the problem is the job just sits on the server. As mentioned before, if I print a test page from the cups interface on the server, it prints fine, so cups on the server can talk to the printer. I can't figure out what the hold up is. Any ideas? It must be some package that cups depends on that is broken, because cups behavior looks OK. I'll keep digging - any thoughts that will shorten the dig are welcomed :) -- David C. Rankin, J.D.,P.E.
On Fri, Feb 10, 2012 at 02:41:52PM -0600, David C. Rankin wrote:
On 02/10/2012 02:05 PM, David C. Rankin wrote:
Guys,
Cups 1.5.2 update caused all user submitted jobs to stick in que and not print.
I'm not convinced this is cups. I just downgraded to 1.5.0 and I still get the same behavior and I was printing before this last set of updated. Here is another bit of information. When the user submits the job, it shows up on the cups 'jobs' list on the server. It just sits there. If I cancel the job on the server, then the client computer job also clears. So the jobs are getting from the client to the server and the client-server can communicate fine, the problem is the job just sits on the server.
As mentioned before, if I print a test page from the cups interface on the server, it prints fine, so cups on the server can talk to the printer. I can't figure out what the hold up is. Any ideas? It must be some package that cups depends on that is broken, because cups behavior looks OK. I'll keep digging - any thoughts that will shorten the dig are welcomed :)
-- David C. Rankin, J.D.,P.E.
Did you restart cups or reboot? I also had the update but no problem printing. But I stay away from KDE. t.
On 02/10/2012 10:48 PM, r8 wrote:
Did you restart cups or reboot? I also had the update but no problem printing. But I stay away from KDE.
Thanks,
Yes, I had restarted cupsd on each box and rebooted each box and I still have
the same problem. I have cleared the print que on both client and server and
restarted cupsd again - same issue. I am using the following cupsd.conf on the
server - the client box uses the default cupsd.conf:
ServerName myhost.mydomain.com
ServerAdmin me@mydomain.com
ServerAlias myhost
ServerAlias www.mydomain.com
ServerAlias localhost
ServerAlias *
Port 631
LogLevel warn
HostNameLookups Off
Timeout 180
PreserveJobFiles Yes
PreserveJobHistory Yes
DefaultPaperSize Letter
SystemGroup sys root wheel
Listen localhost:631
Listen myhost.mydomain.com:631
Listen myhost:631
Listen www.mydomain.com:631
Listen 192.168.6.17:631
Listen /var/run/cups/cups.sock
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS
BrowseRemoteProtocols CUPS
BrowseAddress @LOCAL
DefaultAuthType Basic
<Location />
Satisfy any
Order allow,deny
Allow @LOCAL
Allow 192.168.6.102
</Location>
On 02/11/2012 12:44 PM, David C. Rankin wrote:
Thanks,
Yes, I had restarted cupsd on each box and rebooted each box and I still have the same problem. I have cleared the print que on both client and server and restarted cupsd again - same issue.
Grrr.... This is a linux-to-linux print problem with cups. I can print windows-to-linux just fine. (oh the irony...) Back to debug, print from each and compare logs.... -- David C. Rankin, J.D.,P.E.
On 11-02-2012 20:13, David C. Rankin wrote:
On 02/11/2012 12:44 PM, David C. Rankin wrote:
Thanks,
Yes, I had restarted cupsd on each box and rebooted each box and I still have the same problem. I have cleared the print que on both client and server and restarted cupsd again - same issue.
Grrr....
This is a linux-to-linux print problem with cups. I can print windows-to-linux just fine. (oh the irony...) Back to debug, print from each and compare logs....
Printing on the local machine works fine here (no idea about network printing), do check all the config options, maybe some security/config bug was fixed and that is causing you trouble. -- Mauro Santos
On 02/11/2012 04:05 PM, Mauro Santos wrote:
Printing on the local machine works fine here (no idea about network printing), do check all the config options, maybe some security/config bug was fixed and that is causing you trouble.
I think you are correct. I think it is a libssl or openssl issue. I have a server on the lan that handles network printing: CLIENTS SERVER PRINTERS workstation ---| |--- Laserjet 4200 workstation 2 ---| |--- Sharp M355N workstation 3 ---|------Arch Server (cupsd)-----|--- Laserjet 4100n workstation 4 ---| If the workstation is Linux - it won't print. If it is Win - it prints fine. So something in recent updates has messed up the handshake. -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin
-
Mauro Santos
-
rara8avis＠aol.com