Bug 125786
Summary: | Clicking Apply doesn't restart cups service | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Tod Herman <therman> |
Component: | redhat-config-printer | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | therman |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-07-07 14:49:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tod Herman
2004-06-11 13:54:29 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 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 $? 1 # /sbin/service cups restart Stopping cups: [ OK ] Starting cups: [ OK ] Ran the echo $? out of order when it returned a 1. When run after the cups reload it returns 0 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'. 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. Okay. I couldn't make this happen here when I tried. Thanks. 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 That is intentional: CUPS will delay a reload request until jobs are finished. Are you finding that the behaviour is different than just a delayed restart? 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 running. 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. |