[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> <Location /admin> Satisfy any Order allow,deny Allow @LOCAL Allow 192.168.6.102 </Location> <Location /admin/conf> AuthType Default Require user @SYSTEM Order allow,deny Satisfy any Allow @LOCAL Allow 192.168.6.102 </Location> <snip default stuff> I can't see any problems there. Anything look suspicious? Thanks for any ideas. -- David C. Rankin, J.D.,P.E.
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