Bug 145629 - cups starts on boot after update
Summary: cups starts on boot after update
Alias: None
Product: Fedora
Classification: Fedora
Component: cups   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-20 08:40 UTC by Jeff Moe (jebba)
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-20 11:37:59 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 Jeff Moe (jebba) 2005-01-20 08:40:38 UTC
Description of problem:
After an update of cups it starts on boot, even when the previous
version was set to not start on boot. So if cups is installed, but not
in use, a user who thinks they have it disabled will have it
re-enabled at boot when they upgrade. This may leave them open to
future cups holes (god forbid) when they think the service is off...

Version-Release number of selected component (if applicable):
cups-1.1.22-0.rc1.8.4 and earlier

How reproducible:
Get an older version of cups, turn it off on boot, upgrade.

Steps to Reproduce:
rpm -U --oldpackage cups-1.1.22-0.rc1.8.3.i386.rpm \

chkconfig --del cups

rpm -U cups-1.1.22-0.rc1.8.4.i386.rpm \

chkconfig --list | grep cups    [shows cups on]

Actual results:
Cups is set to start on boot.

Expected results:
Cups is left at it's previous setting to not start on reboot. Apache,
for example, honors it's previous setting.

Additional info:
I don't quite get why this is happening, but I checked out the
differences between cups & httpd. 

Snippets from their specs:
/sbin/chkconfig --add cups || true
/sbin/chkconfig --add httpd

I don't get why they have different behaviour...

Also, it appears in bugzilla there is an entry for "cup" as well (note
no "s").

Comment 1 Tim Waugh 2005-01-20 11:37:59 UTC
Thanks.  This has been fixed in CVS.

(The "cup" bugzilla component is for the "cup" package.)

Comment 2 Jeff Moe (jebba) 2005-01-22 10:03:02 UTC
Ok. I'm being lazy here as I know I should open separate tickets, but
it's late... These packages have a similar problem:

I'm putting it here so it doesn't get lost before I forget. ;)

Also, what was the voodoo to fix it? It would be handy for us lesser
geeks to know how it was fixed in the ticket.

Thanks for the quick fix!

Comment 4 Jeff Moe (jebba) 2005-01-23 00:51:57 UTC
Apparently, `chkconfig off` should be used instead of `--del`, so this
is actually NOTABUG (?). Per pcmcia resolution by davej.

Comment 5 Tim Waugh 2005-01-23 09:00:27 UTC
It's not to do with that at all, but caused by the initscript not
being marked noreplace.

Comment 6 Jeff Moe (jebba) 2005-01-23 10:14:01 UTC
Hmm. Ok, then are the others bugs or not? I closed 'em as NOTABUG
after the pcmcia-cs maintainer (davej) said it wasn't a bug. I can
re-open those, leave closed, or forget. ;)

Also, should /etc/rc.d/init.d/cups really be marked noreplace? I mean,
what if there are improvements/fixes to it in future releases?

I think davej may actually be right `man chckonfig`:
--del name
 The  service is removed from chkconfig management, and any sym-
 bolic links in /etc/rc[0-6].d which pertain to it are  removed.
 Note that future package installs for this service may run chk-
 config --add, which will re-add such links. To disable  a  ser-
 vice, run chkconfig name off.

Sorry if I'm being noisy...

Comment 7 Tim Waugh 2005-01-23 15:34:34 UTC
Yes, it should be noreplace.

Dave said that *you* shouldn't use chkconfig --del, and he's right.  The RPM
scriptlet *should* use it, however, since it runs after the package is removed.

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