FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 02-10-2012, 07:41 PM
"David C. Rankin"
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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.
 
Old 02-11-2012, 03:48 AM
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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.
 
Old 02-11-2012, 05:44 PM
"David C. Rankin"
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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.
 
Old 02-11-2012, 07:13 PM
"David C. Rankin"
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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.
 
Old 02-11-2012, 09:05 PM
Mauro Santos
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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
 
Old 02-12-2012, 02:40 AM
"David C. Rankin"
 
Default update to cups 1.5.2 - test print OK, but nothing else prints - jobs just sit in que until canceled

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.
 

Thread Tools




All times are GMT. The time now is 01:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org