Bug 244001 - Cups delays printing after next reboot (network printer)
Cups delays printing after next reboot (network printer)
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks: F7Update
  Show dependency treegraph
 
Reported: 2007-06-13 05:48 EDT by Nicolò
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-29 05:03:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CUPS error log (157.08 KB, text/plain)
2007-06-15 11:10 EDT, Nicolò
no flags Details
tcpdump (21.55 KB, application/octet-stream)
2007-06-15 13:35 EDT, Nicolò
no flags Details

  None (edit)
Description Nicolò 2007-06-13 05:48:16 EDT
Description of problem:
Printing a document have no effect immediately, but printed document is somehow
saved and printed just after the next reboot

Version-Release number of selected component (if applicable):
libgnomecups-0.2.2-8
cups-libs-1.2.10-10.fc7
hal-cups-utils-0.6.9-1.fc7
cups-1.2.10-10.fc7


How reproducible:
Always

Steps to Reproduce:
1. configure network printer (Hp deskjet 845c) attached to USRobotics router
2. print something, nothing happens
3. reboot, document is printed
  
Actual results:
Printing delayed until next boot

Expected results:
Printing should happen within reasonable time, without having to reboot

Additional info:
I am sure this is not caused by the router or the printer, because the other pc
connected to it (Windows XP) prints just after some seconds

Also: "/etc/init.d/cups restart" is not enough, it needs to reboot.

Sorry I have not tried with direct USB connection of the printer, but can do if
required
Comment 1 Tim Waugh 2007-06-13 05:57:15 EDT
I'd like some additional information in order to track down the problem.

1. What does 'lpstat -t' say?
2. What does 'lpstat -o' say?
Comment 2 Nicolò 2007-06-13 06:16:58 EDT
lpstat -t
scheduler is running
system default destination: Hp
device for Hp: http://192.168.1.1:1631/printers/Hpdeskjet845c
Hp accepting requests since Wed 13 Jun 2007 11:41:34 AM CEST
printer Hp now printing Hp-10.  enabled since Wed 13 Jun 2007 11:41:34 AM CEST
        Connected to 192.168.1.1...
Hp-5                    fabrizio         55296   Tue 12 Jun 2007 07:00:06 PM CEST
Hp-6                    fabrizio         55296   Tue 12 Jun 2007 07:03:23 PM CEST
Hp-7                    fabrizio         55296   Tue 12 Jun 2007 07:26:00 PM CEST
Hp-8                    fabrizio         55296   Tue 12 Jun 2007 08:30:27 PM CEST
Hp-9                    fabrizio         55296   Tue 12 Jun 2007 08:30:32 PM CEST
Hp-10                   nicko             6144   Wed 13 Jun 2007 11:40:38 AM CEST



lpstat -o
Hp-5                    fabrizio         55296   Tue 12 Jun 2007 07:00:06 PM CEST
Hp-6                    fabrizio         55296   Tue 12 Jun 2007 07:03:23 PM CEST
Hp-7                    fabrizio         55296   Tue 12 Jun 2007 07:26:00 PM CEST
Hp-8                    fabrizio         55296   Tue 12 Jun 2007 08:30:27 PM CEST
Hp-9                    fabrizio         55296   Tue 12 Jun 2007 08:30:32 PM CEST
Hp-10                   nicko             6144   Wed 13 Jun 2007 11:40:38 AM CEST

Please note that document of user nicko (me) still has to be printed
If you need something else, just let me know
Comment 3 Nicolò 2007-06-13 06:30:32 EDT
Don't know if this is useful, but I have found out that reboot is not required:
Hybernation is enough
Comment 4 Tim Waugh 2007-06-15 07:04:23 EDT
I'd like to try a test print with some debugging on if that's okay.  First I'd
like to you start with no jobs in the queue.  Then, as root:

1. Edit /etc/cups/cupsd.conf so that the 'LogLevel' line reads:

LogLevel debug2

2. Stop CUPS:

/sbin/service cups stop

3. Clear out the error_log file:

>/var/log/cups/error_log

4. Now start CUPS:

/sbin/service cups start

5. Submit a print job and give it some time to try printing it.

When you have done that, if the job has failed to print please attach the
/var/log/cups/error_log file to this bug report as an attachment.  Thanks.
Comment 5 Nicolò 2007-06-15 11:10:07 EDT
Created attachment 157121 [details]
CUPS error log

Here it is, please let me know if you are also interested in the same log after
next boot (when it will print, I'm quite sure about that... )
Comment 6 Nicolò 2007-06-15 11:44:00 EDT
I have noticed that the file has continued to grow in the past minutes, but it
just keeps repeating that cups will delay its job for 11 seconds
(d [15/Jun/2007:17:34:03 +0200] select_timeout: 11 seconds to process active jobs
d [15/Jun/2007:17:34:14 +0200] cupsdCheckJobs: 1 active jobs, sleeping=0, reload=0
d [15/Jun/2007:17:34:14 +0200] cupsdCheckJobs: Job 12: state_value=5, loaded=yes
d [15/Jun/2007:17:34:14 +0200] select_timeout: 9 seconds to send browse update)
every 11 seconds, and it is not likely to stop very soon...
Comment 7 Tim Waugh 2007-06-15 12:00:14 EDT
Yes, that's expected -- this is with debug logging enabled.  You can turn it
back off now:

1. edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read:

LogLevel info

2. Tell CUPS to reload its configuration:

/sbin/service cups reload

~~~

So the ipp backend is getting stuck soon after it connects.  I'd like to try
another test, this time to see what happens on the TCP connection.

1. Start with no jobs in the queue, as before.
2. In a terminal window, as root, please run this command to capture the TCP
traffic:

tcpdump -w printer.pcap -U -s 0 port 1631

3. Submit a print job and wait about five minutes, enough to give it time to try
to print it.  If the job prints successful, try another -- I need to see the log
from a *failed* job.
4. Press Control-C to stop tcpdump.
5. Attach the printer.pcap file as an attachment to this bug report.

Thanks.
Comment 8 Nicolò 2007-06-15 13:35:42 EDT
Created attachment 157136 [details]
tcpdump

How did you know I had to try twice? This is the first time it prints
immediately...

However, this is the log for the failed one
Comment 9 Nicolò 2007-06-21 12:28:49 EDT
You didn't tell me if you needed something else...
Comment 10 Tim Waugh 2007-06-29 05:03:09 EDT
We send an IPP-Print-Job request to the US Robotics ADSL 4-Port Router device,
with 'Content-Length: 17631', however after sending exactly that many bytes
there is no response.

The problem lies with the US Robotics device.

Note You need to log in before you can comment on or make changes to this bug.