Bug 125786 - Clicking Apply doesn't restart cups service
Summary: Clicking Apply doesn't restart cups service
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-config-printer   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-11 13:54 UTC by Tod Herman
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-07 14:49:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Tod Herman 2004-06-11 13:54:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 
7.50  [en]

Description of problem:
Clicking Apply within the redhat-config-printer gui to apply changes 
is supposed to restart the cups service.  Currently, clicking apply 
applies any changes, but only stops the cups service requiring then a 
manual start

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

How reproducible:

Steps to Reproduce:
1.Open Redhat-Config-Printer
2.Make changes to a print queue
3.Click on Apply

Actual Results:  After clickingon apply, the changes are applied but 
instead of restarting the cups service, the service is stopped

Expected Results:  the cups service should be restarted

Additional info:

Comment 1 Tim Waugh 2004-06-25 08:08:17 UTC
What does it say when you run the following commands (as root)?:

/usr/sbin/alternatives --display print
/sbin/service cups reload
echo $?
/sbin/service cups restart

Comment 2 Tod Herman 2004-06-29 15:04:01 UTC
Here are the results you requested:

/usr/sbin/alternatives --display print
print - status is auto.
 link currently points to /usr/bin/lpr.cups
/usr/bin/lpr.cups - priority 40
 slave print-lp: /usr/bin/lp.cups
 slave print-lpq: /usr/bin/lpq.cups
 slave print-lprm: /usr/bin/lprm.cups
 slave print-lpstat: /usr/bin/lpstat.cups
 slave print-cancel: /usr/bin/cancel.cups
 slave print-lpc: /usr/sbin/lpc.cups
 slave print-cancelman: /usr/share/man/man1/cancel-cups.1.gz
 slave print-lpman: /usr/share/man/man1/lp-cups.1.gz
 slave print-lpcman: /usr/share/man/man8/lpc-cups.8.gz
 slave print-lpqman: /usr/share/man/man1/lpq-cups.1.gz
 slave print-lprman: /usr/share/man/man1/lpr-cups.1.gz
 slave print-lprmman: /usr/share/man/man1/lprm-cups.1.gz
 slave print-lpstatman: /usr/share/man/man1/lpstat-cups.1.gz
Current `best' version is /usr/bin/lpr.cups.

# /sbin/service cups reload
Reloading cups:                                            [  OK  ]

# echo $?

# /sbin/service cups restart
Stopping cups:                                             [  OK  ]
Starting cups:                                             [  OK  ]

Comment 3 Tod Herman 2004-06-29 18:47:00 UTC
Ran the echo $? out of order when it returned a 1.  When run after 
the cups reload it returns 0

Comment 4 Tim Waugh 2004-07-01 12:01:21 UTC
Is cups running after a reload?  What does this say?:

/sbin/service cups status
/sbin/service cups reload
/sbin/service cups status

system-config-printer never runs '/sbin/service cups stop', only
'reload' and 'restart'.

Comment 5 Tod Herman 2004-07-07 14:46:51 UTC
Currently, both restart and reload are functioning correctly.  I can 
no longer duplicate the problem as stated originally.  Don't know 
what caused the change for the better.  Please consider this bug 
closed and thanks for your help.

Comment 6 Tim Waugh 2004-07-07 14:49:21 UTC
Okay.  I couldn't make this happen here when I tried.  Thanks.

Comment 7 Tod Herman 2004-09-15 16:29:23 UTC
while continuing to work with the printer gui and the new system, 
i've found that the issue reported above is still a problem.  But to 
clarify, the problem only exists when you try to click apply (or do a 
cups reload) when there is a print job or jobs active in any of the 
print queues.  If all the queues are empty, the service reloads 
properly.  When a job is present in a queue, cups will show that it 
isn't running after hitting apply or doing a service cups reload.  
Hope this helps

Comment 8 Tim Waugh 2004-09-27 17:11:28 UTC
That is intentional: CUPS will delay a reload request until jobs are

Are you finding that the behaviour is different than just a delayed

Comment 9 Tod Herman 2004-09-27 18:14:38 UTC
Hate to answer a question with a question, but if I had waited long 
enough would the cups service have started if there was the 
intentional delay you're referring to?  I didn't get the impression 
that the service was going to start back up after it stopped.Each 
time this has happened, the service stopped after clicking apply.  I 
manually started the service immediately, once I knew that this was 
how it was working. The first few times, we didn't know what was 
happening, only that we eventually saw that the service wasn't 

Comment 10 Tim Waugh 2004-09-28 08:09:59 UTC
You shouldn't have had to wait too long.  Perhaps a minute after the
jobs finish?

It won't accept new jobs after a reload request (but before the actual
reload), of course.

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