Bug 190970 - cups print server fails unexpectedly
cups print server fails unexpectedly
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-07 12:56 EDT by Randy Cushman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-25 08:54:22 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)
'ps axf' output with system functioning normally (7.79 KB, text/plain)
2006-05-09 14:21 EDT, Randy Cushman
no flags Details

  None (edit)
Description Randy Cushman 2006-05-07 12:56:34 EDT
Description of problem:
printing to printer served by cups on FC5 fails unexpectedly
Symptoms of failure:
- unable to print locally
- unable to print from Windows XP system
- other systems running FC5 and MAC OS X do not receive printer information
broadcasts
- unable to view printer config using browser and http://localhost:631
- printer config gui hangs
- command 'lpq' reports "lpq: Unable to contact server!"

Version-Release number of selected component (if applicable):
cups-1.1.23-30.2

How reproducible:
Failure appears to correspond to scheduled server restarts
End of file /var/log/cups/error_log.1:
I [07/May/2006:04:02:20 -0500] Scheduler shutting down normally.

Beginning of file error_log:
I [07/May/2006:04:02:20 -0500] Sending browsing info to c0a801ff:631
I [07/May/2006:04:02:20 -0500] Listening to c0a80102:631
I [07/May/2006:04:02:20 -0500] Listening to 7f000001:631
I [07/May/2006:04:02:20 -0500] Loaded configuration file "/etc/cups/cupsd.conf"
I [07/May/2006:04:02:20 -0500] Configured for up to 100 clients.
I [07/May/2006:04:02:20 -0500] Allowing up to 100 client connections per host.
I [07/May/2006:04:02:20 -0500] Full reload is required.
W [07/May/2006:04:02:51 -0500] LoadDevices: Backend did not respond within 30
seconds!


Steps to Reproduce:
1. failure occurs without any user action taken
2.
3.
  
Actual results:
See description

Expected results:
command 'lpq' reports:
    LJ is ready
    no entries
etc.

Contents of log file after restart:
I [07/May/2006:08:55:55 -0500] Sending browsing info to c0a801ff:631
I [07/May/2006:08:55:55 -0500] Listening to c0a80102:631
I [07/May/2006:08:55:55 -0500] Listening to 7f000001:631
I [07/May/2006:08:55:55 -0500] Loaded configuration file "/etc/cups/cupsd.conf"
I [07/May/2006:08:55:55 -0500] Configured for up to 100 clients.
I [07/May/2006:08:55:55 -0500] Allowing up to 100 client connections per host.
I [07/May/2006:08:55:55 -0500] Full reload is required.
I [07/May/2006:08:55:55 -0500] LoadPPDs: Read "/etc/cups/ppds.dat", 1286 PPDs...
I [07/May/2006:08:55:55 -0500] LoadPPDs: No new or changed PPDs...
I [07/May/2006:08:55:55 -0500] Full reload complete.


Additional info:
At time of malfunction, 'ps aux' shows 2 instances of 'cupsd' running

Steps to correct:
- execute '/etc/init.d/cups stop'
- wait several seconds
- execute '/etc/init.d/cups start'

System features Athlon 64 x2 4200+ dual-core CPU and 2 GB RAM, with OS running
in SMP mode.
Comment 1 Tim Waugh 2006-05-08 04:36:29 EDT
I expect that 'ps axf' would show that one cupsd instance was forked by the other.

Seems like one of the backends has got stuck.  Could you try this, as root?:

chmod -x /usr/lib64/cups/backend/serial

Does that work around the problem?
Comment 2 Randy Cushman 2006-05-08 12:41:08 EDT
My knowledge of Linux systems administration is limited.  How do I change the
restart schedule for cupsd, so I can experiment more often than weekly?
Comment 3 Tim Waugh 2006-05-08 16:43:21 EDT
This is happening when the logs are rotated, and you should be able to trigger
it like this:

/sbin/service cups condrestart

(since that's what the log rotation script does)
Comment 4 Randy Cushman 2006-05-08 21:05:55 EDT
I executed the command:
/sbin/service cups condrestart
as instructed.  I have not yet performed the 'chmod' change.

This command did not reproduce the problem.

Log entries recorded in /var/log/cups/error_log since the above command was
executed:
I [08/May/2006:19:49:12 -0500] Scheduler shutting down normally.
I [08/May/2006:19:49:12 -0500] Sending browsing info to c0a801ff:631
I [08/May/2006:19:49:12 -0500] Listening to c0a80102:631
I [08/May/2006:19:49:12 -0500] Listening to 7f000001:631
I [08/May/2006:19:49:12 -0500] Loaded configuration file "/etc/cups/cupsd.conf"
I [08/May/2006:19:49:12 -0500] Configured for up to 100 clients.
I [08/May/2006:19:49:12 -0500] Allowing up to 100 client connections per host.
I [08/May/2006:19:49:12 -0500] Full reload is required.
I [08/May/2006:19:49:12 -0500] LoadPPDs: Read "/etc/cups/ppds.dat", 1286 PPDs...
I [08/May/2006:19:49:12 -0500] LoadPPDs: No new or changed PPDs...
I [08/May/2006:19:49:12 -0500] Full reload complete.

Thoughts?  Is there some system performance monitoring I could run during the
time of the next log rotation?
Comment 5 Tim Waugh 2006-05-09 03:53:39 EDT
Yes, you could attach the output of 'ps axf' here -- that should enable us to be
sure about which backend is failing.
Comment 6 Randy Cushman 2006-05-09 14:21:01 EDT
Created attachment 128803 [details]
'ps axf' output with system functioning normally

I'm not sure whether you want the 'ps axf' output from now while the system is
functioning normally, or after Sunday, when cupsd will (I predict) fail again,
so I'll provide both.
Comment 7 Randy Cushman 2006-05-16 16:14:37 EDT
The problem did not occur during this past Sunday (14 May)'s logrotate.

I recently removed a printer from the configuration.  (The configuration was for
a dot-matrix printer that was normally powered off.)  Unfortunately I did not
note the date of this change, although I estimate it was May 5--before the last
failure on 7 May.  I re-added the printer config before I thought to make note
of the previous config file modification date.

If the failure does not recur this coming Sunday, I'll assume that I
inadvertently fixed a configuration issue, and that I can no longer reproduce
the issue.
Comment 8 Randy Cushman 2006-05-21 11:17:20 EDT
I can no longer reproduce this issue.

Feel free to mark the issue resolved.
Comment 9 Tim Waugh 2006-05-21 12:25:49 EDT
What does 'rpm -q cups' say now?

Can you reproduce the problem at all by using the command '/usr/sbin/lpinfo -v'
as root?
Comment 10 Randy Cushman 2006-05-22 15:10:20 EDT
# rpm -q cups
cups-1.1.23-30.2

# /usr/sbin/lpinfo -v
network socket
network beh
direct hal
direct hp:/no_device_found
network http
network ipp
network lpd
direct parallel:/dev/lp0
direct parallel:/dev/lp1
direct parallel:/dev/unknown-parallel2
direct scsi
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyS1?baud=115200
serial serial:/dev/ttyS2?baud=115200
serial serial:/dev/ttyS3?baud=115200
direct usb:/dev/usb/lp0
direct usb:/dev/usb/lp1
direct usb:/dev/usb/lp2
direct usb:/dev/usb/lp3
direct usb:/dev/usb/lp4
direct usb:/dev/usb/lp5
direct usb:/dev/usb/lp6
direct usb:/dev/usb/lp7
direct usb:/dev/usb/lp8
direct usb:/dev/usb/lp9
direct usb:/dev/usb/lp10
direct usb:/dev/usb/lp11
direct usb:/dev/usb/lp12
direct usb:/dev/usb/lp13
direct usb:/dev/usb/lp14
direct usb:/dev/usb/lp15
network smb


Miscellaneous notes:

- Back when the trouble was occurring, I noticed that executing the
command /etc/init.d/cups restart' would hang on 'Starting cups:" 
(although I would kill the script before 30 seconds had elapsed). 
As I mentioned, issuing 'stop', then waiting several seconds
(probably less than 10) then issuing 'start' worked OK.  This
symptom also is no longer occurring.

- I haven't updated any packages since the last time the failure
occurred.

I suspect that the only way to reproduce this issue would be to
restore the relevant config files (from backup) to their state when
the issue was occurring.  If you would like for me to try this, let
me know which files I should include.
Comment 11 Tim Waugh 2006-05-25 08:54:22 EDT
No, it's alright.  Glad it's fixed.  If you happen across the problem again,
please do re-open this report though.  Thanks.

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