This isn't the fault of CUPS but of whichever process is creating these subscriptions.

Are you running GNOME or KDE or some other desktop session on that machine locally?

What's in /etc/cups/subscriptions.conf?

Created attachment 663659 [details]
subscriptions.conf

Of course I deleted the subscriptions.conf which was causing the problem, but here is what it says currently.  There are ten processes running with a total VSZ of 775MB; six of them have been there since yesterday (I'm posting this at approx 16:30).

The machine is running headless in runlevel 3 and doesn't have any desktop managers installed.  Note that none of the users mentioned in the "Owner" lines in subscriptions.conf actually has an account on the machine.

How are the clients configured?  i.e. how do they know to send print jobs to that machine?

In general they have ServerName specified in /etc/cups/client.conf.  A few of the clients will instead have a printer configured in their local cups daemon with an ipp:// URI (pointing at the server) specified as the printer location.

Thanks.  And are the clients running GNOME?

gnome-settings-daemon's print-notifications plugin sets a notify_recipient_uri of "dbus:///" even for non-"localhost" servers, which is silly.

Changing component and reassigning.

Really it should poll a subscription (that has no notify_recipient_uri) using Get-Notifications, and only use a notify_recipient_uri=dbus:/// subscription to be notified about when to poll.  This is what system-config-printer does (I'm fairly sure I suggested that scheme when the print-notifications plugin was first being developed).

In other words, the logic should be:

if cupsServer() == "localhost":
  sub_optimization = conn.createSubscription(notify_recipient_uri="dbus:///", ...)

sub_required = conn.createSubscription(...)
set_timer (60 seconds, get_notifications)
if sub_optimization:
  set_dbus_signal_handler (..., get_notifications)

And in get_notifications:
  n = conn.getNotifications ()
  for event in n['events']:
    # deal with each event from the getNotifications response
  set_timer (n['notify-get-interval'], get_notifications)

So the actual events would be fetched from the IPP response, and the D-Bus signal would just be a clue to fetch notifications.  Of course, you can choose which events will trigger D-Bus signals to match the ones you're interested in.

OK.  It's a fair guess that most clients would run GNOME, yes.

I think I have now succeeded in fixing this on the server anyway, by implementing a policy which denies non-local subscription requests.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

gnome-settings-daemon-3.8.4-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gnome-settings-daemon-3.8.4-2.fc19

Package gnome-settings-daemon-3.8.4-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-settings-daemon-3.8.4-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14394/gnome-settings-daemon-3.8.4-2.fc19
then log in and leave karma (feedback).

gnome-settings-daemon-3.8.4-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.