#1701 Disable cups service by default in most editions
Closed: Fixed 6 years ago Opened 6 years ago by pfrields.

The Workstation WG approved a preset change to turn on cups on-demand socket activation (https://pagure.io/fedora-release/pull-request/93). @sgallagh advised that we should also put the option out for FESCo to disable the service by default in the other editions.


To clarify the request, CUPS currently has the following set in 90-defaults.preset in the fedora-release package:

enable cups.*

What this expands out to is cups.socket, cups.path and cups.service. Since cups.service can nowadays be auto-started by cups.socket, it is suggested that we could reduce our resource usage by not starting CUPS unconditionally on the system until it's actually being used.

I'm +1 for this change (and if FESCo agrees, I'll submit a PR to update the presets).

Adding to the agenda for tomorrow's FESCo meeting (Friday 16:00 UTC).

CC cups maintainers @zdohnal @twaugh @jpopelka

Metadata Update from @kalev:
- Issue tagged with: meeting

6 years ago

Hi,

I think we can disable cups.service on Workstation and Spins edition, but let it enabled on Server, Docker and Cloud editions (editions, which can act as print servers with the most probability). That's because print queue on server can be configured to be shared with client, which needs to have running cups.service.

Hi,
I think we can disable cups.service on Workstation and Spins edition, but let it enabled on Server, Docker and Cloud editions (editions, which can act as print servers with the most probability). That's because print queue on server can be configured to be shared with client, which needs to have running cups.service.

@zdohnal Can you clarify what "print queue on server can be configured to be shared with client" means? Also, if it requires custom configuration, I don't think that should impact the decision about how to set the defaults (since if someone is modifying the service to run in a non-standard way, configuring a unit file to start is not an unreasonably heavy additional requirement).

But why would the clients not be causing it to autostart via the socket activation anyway?

@sgallagh It means when you install shared (printer can be accessed by anyone who has permissions to access CUPS system on server - you cannot access it without running cups service, server "shares" that printer) printer on server system (that installation creates shared print queue), you can view it from client system only when cups service is running . I think it is the most simple way to access remote printer without need of dnssd.
I know, dnssd is now preferable, but I think that breaking this other option is not good idea. And I would like to ask: how is this disabling can reduce resources? When cups.service is either way started by cups-browsed service or any lp* command and stays running after that? I only see pros in missing symlink and maybe faster start-up.

  • AGREED: Drop cups.service from the 90-default.preset file. Defer to Server WG on whether to leave it enabled on that Edition. (+1:7, 0:0, -1:0) (kalev, 16:21:55)
  • ACTION: sgallagh to take the question to Server WG (sgallagh, 16:22:12)

Metadata Update from @kalev:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata