Bug 744078 - system settings/printers broken
Summary: system settings/printers broken
Keywords:
Status: CLOSED DUPLICATE of bug 748841
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 748521 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-06 22:10 UTC by Benjamin Kosnik
Modified: 2013-08-09 05:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-07 16:39:06 UTC


Attachments (Terms of Use)

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:
1.
2.
3.
  
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


2. 

%rpm -q cups
cups-1.5.0-16.fc16.x86_64


3. see #1

4. 

%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.

cups-1.5.0-16.fc16.x86_64

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 ***


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