Bug 744078

Summary: system settings/printers broken
Product: [Fedora] Fedora Reporter: Benjamin Kosnik <bkoz>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: jpopelka, mishu, mnewsome, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-07 16:39:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Benjamin Kosnik 2011-10-06 22:10:35 UTC
Description of problem:

install f16 x86_64 on KVM virtual machine. Go to system settings -> printers and attempt to configure a printer. This is not possible, instead there is a sad computer icon and the following message:

Sorry! The system printing services do not seem to be available

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Tim Waugh 2011-10-07 08:48:50 UTC
I need more information than this.

1. Which F-16 ISO did you install from initially, and have you applied updates since then?
2. What does 'rpm -q cups' say?
3. What does 'systemctl status cups.service' say?
4. What about 'systemctl status cups.socket'?

Comment 2 Tim Waugh 2011-10-25 08:17:21 UTC
*** Bug 748521 has been marked as a duplicate of this bug. ***

Comment 3 Benjamin Kosnik 2011-10-26 17:56:50 UTC
Hey Tim.

1. I have tried TC2 live, dvd, and netinstall media on both virtual and real hardware. They all have this issue.

If I do

service cups start

On boot, I get:

then things work as expected.%service cups status
Redirecting to /bin/systemctl  status cups.service
cups.service - CUPS Printing Service
	  Loaded: loaded (/lib/systemd/system/cups.service; disabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/cups.service


%rpm -q cups

3. see #1


%systemctl status cups.socket
cups.socket - CUPS Printing Service Sockets
	  Loaded: loaded (/lib/systemd/system/cups.socket; disabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/cups.socket

Comment 4 Benjamin Kosnik 2011-10-26 17:57:52 UTC
oops. To clarify, cups Dead on Boot. But if I do:

service cups start

then it's live and I can configure as per normal.

Comment 5 Tim Waugh 2011-10-27 11:57:29 UTC
When I boot 16.TC2/Live/x86_64/Fedora-16-TC-x86_64-Live-Desktop.iso in a virtual machine, then start a gnome-terminal, I get this:

cups.service - CUPS Printing Service
	  Loaded: loaded (/lib/systemd/system/cups.service; enabled)
	  Active: active (running) since Thu, 27 Oct 2011 07:50:25 -0400; 43s ago
	Main PID: 1365 (cupsd)
	  CGroup: name=systemd:/system/cups.service
		  └ 1365 /usr/sbin/cupsd -f

System Settings -> Printers works fine.


What are we doing differently?

Comment 6 cblaauw 2011-10-28 11:33:00 UTC
I did the installation of F16 via preupgrading F15. There is not cups.service under /etc/systemd. Setting a link in multi-user.target.wants to /lib/systemd/system/cups.service solves the problem for me and cups is started on boot.

Comment 7 Tim Waugh 2011-10-28 12:02:38 UTC
cblaauw: this is expected behaviour for upgrades.  See bug #748841 comment #1.

For fresh installations, however, CUPS ought to be enabled by default.  Benjamin, how can I reproduce the problem you are seeing?

Comment 8 Benjamin Kosnik 2011-10-31 18:29:51 UTC
Interesting that the upgrades DNW, I didn't know that.

I just updated my non-virtual TC2 install, and things seem to be working correctly now, without manual intervention to start cups.

When F16 is released, I'll re-install on my workstation and confirm that this bug is still present. This time I'll do a standard print install first and check, before installing all the foomatic stuff that I usually use.

Comment 9 Tim Waugh 2011-11-01 10:40:52 UTC
Well, in fact, there was a bug preventing upgrades from setting the correct default enabled/disabled state. :-(  See bug #748841 comment #3 onwards...

Comment 10 Tim Waugh 2011-11-07 16:39:06 UTC

*** This bug has been marked as a duplicate of bug 748841 ***