Bug 145629 - cups starts on boot after update
cups starts on boot after update
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-20 03:40 EST by Jeff Moe (jebba)
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-20 06:37:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Moe (jebba) 2005-01-20 03:40:38 EST
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:
1.
rpm -U --oldpackage cups-1.1.22-0.rc1.8.3.i386.rpm \
cups-libs-1.1.22-0.rc1.8.3.i386.rpm

2.
chkconfig --del cups

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

4.
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:
cups:
/sbin/chkconfig --add cups || true
httpd:
/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 06:37:59 EST
Thanks.  This has been fixed in CVS.

(The "cup" bugzilla component is for the "cup" package.)
Comment 2 Jeff Moe (jebba) 2005-01-22 05:03:02 EST
Ok. I'm being lazy here as I know I should open separate tickets, but
it's late... These packages have a similar problem:
iiim
pcmcia
sendmail

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-22 19:51:57 EST
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 04:00:27 EST
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 05:14:01 EST
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 10:34:34 EST
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.