CUPS web interface stops responding after a while

Bug #1598300 reported by dominix on 2016-07-01
This bug affects 12 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)

Bug Description

after 6 minutes or so, cups is not responding.
it do not produce error on the log, just stop working, worse, it exit with 0

|root@cupsmachine :~# systemctl status cups |
|● cups.service - CUPS Scheduler |
| Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)|
| Active: inactive (dead) since ven. 2016-07-01 10:31:32 TAHT; 2min 16s ago |
| Docs: man:cupsd(8) |
| Process: 28686 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS) |
| Main PID: 28686 (code=exited, status=0/SUCCESS) |
| |
|juil. 01 10:30:01 appli-client systemd[1]: Started CUPS Scheduler. |

I got to launch it again, so I have finish with a cron job like
*/10 * * * * systemctl status cups.service|grep -q 'inactive (dead)' && systemctl start cups

but it is a dirty solution. I have no idea of what make it stop.
NB: I have seen problems related to apparmor, this machine has no apparmor package.


If you want to use the CUPS web interface in Xenial and therefore set "WebInterface Yes" in /etc/cups/cupsd.conf, CUPS could auto-shutdown when it is idle and then an attempt to access http://localhost:631/ via a web browser fails. People get confused as other access to CUPS


Take a CUPS setup on Xenial with no shared print queues and CUPS only listening on the domain socket. Activate the web interface via

cupsctl WebInterface=Yes

Now you are able to access the web interface via http://localhost:631/. Wait for some minutes without accessing CUPS until the CUPS daemon shuts down automatically. Try to open the web interface again and it will not work.

With the fixed CUPS package CUPS will not auto-shutdown when the web interface is activated.

[Regression Potential]

Low, as we are removing a simple distro patch to get back to the original, upstream behavior.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cups (Ubuntu):
status: New → Confirmed
Janne Paalijarvi (jpaalija) wrote :

I have exactly the same thing on 16.04 LTS with the minimal virtual machine install. I run the whole thing on ESXi 5.5 something.

root@printserver:/var/log/cups# service cups status
● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: inactive (dead) since Wed 2016-08-24 22:44:57 EEST; 12min ago
     Docs: man:cupsd(8)
  Process: 2177 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 2177 (code=exited, status=0/SUCCESS)

Aug 24 22:38:23 printserver systemd[1]: Started CUPS Scheduler.

No mention of any abnormalities in any logs whatsoever. I'm afraid I need to go back to 14.04 LTS for this virtual machine.

Till Kamppeter (till-kamppeter) wrote :

Please follow the instructions of the section "CUPS error_log" on Thanks.

Changed in cups (Ubuntu):
status: Confirmed → Incomplete
Stephan (meistadieb) wrote :

The same for me:

● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: inactive (dead) since Di 2016-08-30 08:42:33 CEST; 34min ago
     Docs: man:cupsd(8)
  Process: 11682 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 11682 (code=exited, status=0/SUCCESS)

error_log attached. Nothing special in there. cups is just going inactive and doesn't come back. A 'sudo service cups restart' fixes the problem until the next reboot:

● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: active (running) since Di 2016-08-30 09:19:19 CEST; 2min 26s ago
     Docs: man:cupsd(8)
 Main PID: 17018 (cupsd)
   CGroup: /system.slice/cups.service
           ├─17018 /usr/sbin/cupsd -l
           └─17025 /usr/lib/cups/notifier/dbus dbus://

Stephan (meistadieb) wrote :

A little correction: 'sudo service cups restart' only solves the problem for a short time, not necessarily till the next reboot.

Iiro Laiho (iiro) wrote :

This seems to be a some kind of desktop/laptop power/resource saving feature that does not take Web UI to the account. CUPS will immediately start up again if I open the printing dialog or something.

When I read Stephan's error log as well as my own, it reads:

"I [30/Aug/2016:08:42:33 +0200] Printer sharing is off and there are no jobs pending, will restart on demand.
I [30/Aug/2016:08:42:33 +0200] Scheduler shutting down normally."

Maybe some kind of xinetd setup would make it possible to shut CUPS down but start it up when one tries to access the web UI.

Please do not expire this bug, that is not a solution. and Stephan has provided the requested error log. WONTFIX would be a better solution if this is the way it is intended to work.

Till Kamppeter (till-kamppeter) wrote :

I posted an upstream feature request now to improve the web interface for CUPS running on-demand. See

Till Kamppeter (till-kamppeter) wrote :

First, xinetd is not needed. systemd handles running services on-demand well.

Important to know is that there are two access methods for CUPS:

1. The domain socket file /var/run/cups/cups.sock

2. IP Port 631

CUPS can be configured to use one of these methods or both.

Both methods can be used and the applications printing via CUPS and correctly implemented (usually using libcups) automatically choose a suitable method.

As web browsers can only access network locations, the CUPS web interface is only available via port 631, for example under the URI http://localhost:631/. This means that a CUPS only configured for the domain socket cannot use the web interface at all.

When I look at the systemd files which describe how to automatically start CUPS, I see only a /lib/systemd/system/cups.socket which starts CUPS by traffic on the domain socket and /lib/systemd/system/cups.service which starts CUPS on boot. I do not see some systemd instruction file making CUPS triggered via port 631. This seems to be the problem.

By the way, Mike Sweet, author of CUPS, tells that the web interface should work with on-demand CUPS daemon. See

Till Kamppeter (till-kamppeter) wrote :

I tried now the following:

till@till-x1carbon:~/printing/cups/bzr/y$ sudo systemctl stop cups
Warning: Stopping cups.service, but it can still be activated by:
till@till-x1carbon:~/printing/cups/bzr/y$ ps auxwww | grep cupsd
till 4265 0.0 0.0 14224 896 pts/19 S+ 23:33 0:00 grep --color=auto cupsd

Accessed http://localhost:631/ in web browser --> FAILED.

till@till-x1carbon:~/printing/cups/bzr/y$ lpstat -r
scheduler is running

Accessed http://localhost:631/ in web browser --> SUCCEEDED (the "lpstat -r" triggered cupsd by
                                                             domain socket)

till@till-x1carbon:~/printing/cups/bzr/y$ ps auxwww | grep cupsd
root 4290 1.4 0.1 169908 10260 ? Ssl 23:33 0:00 /usr/sbin/cupsd -l
till 4311 0.0 0.0 14224 1056 pts/19 S+ 23:33 0:00 grep --color=auto cupsd

So for the web interface we need some systemd unit file which triggers CUPS via port 631. Any example files welcome.

Changed in cups (Ubuntu):
status: Incomplete → Confirmed
Stephan (meistadieb) wrote :

Nice to see some progress, but the initial problem description and mine is different from what has been discovered. The problem is not just the webinterface, it is cups itself (or the scheduler) which goes inactive and doesn't come back.

Today I was able to invest more time. On my system there was still a client.conf in /etc/cups/ The man page says it is deprecated. I moved it to client.conf_bak and restarted cups. The scheduler is now running for over 3 hours. I will have an eye on this, but maybe this fixed my cups problem.

I have done some tests and have found a solution. Please try it out.

Edit the file (with sudo):


adding a line


in the "[Socket]" section. The file should look like this then:

Description=CUPS Scheduler



Now make sure that this does not produce any editor backup files, like /lib/systemd/system/cups.socket~ or /lib/systemd/system/cups.socket.backup. Remove such files now.

Now restart systemd with the command

sudo systemctl daemon-reload

Now systemd does not only restart CUPS via the domain socket but also via port 631, meaning that it also gets started when trying to access via the web interface (or any other application which accesses only via port 631).

Please try it out.

If you do not want to wait everytime until CUPS stops by itself for doing the tests, you can stop it with

sudo systemctl stop cups

What was in your /etc/cups/client.conf (now /etc/cups/client.conf_bak)? If it pointed to a CUPS on a remote machine, all your CUPS access (from applications/command line, not web interface) was directed to the remote machine with a different CUPS setup. Now you are using always the CUPS on your local machine.

Note that client.conf is deprecated but still working as originally intended (and so often an admin's nightmare).

dominix (dominix-launchpad) wrote :

hi Till,
there is no client.* in /etc/cups

dominix (dominix-launchpad) wrote :

edited /lib/systemd/system/cups.socket

restarted systemd and cups.

waiting for the bug to come back ...

Stephan (meistadieb) wrote :

in my /etc/cups/client.conf (now /etc/cups/client.conf_bak) are two lines:
ServerName NameoftheremoteCUPSServer
ServerName localhost

The remote CUPS Server is running Version 1.5.3 and my client 2.0.2.

Not having "ListenStream=631" in the systemd cups.socket file is intended. See the answer from Mike Sweet, author of CUPS:

First, the reason why we don't include "ListenStream=631" is because that exposes cupsd to remote attack. And we don't listen on localhost (which has a similar security issue) because it causes problems when binding to the "any" address on Linux.

Second, once cupsd starts it will create the localhost (or "any" address) listener for you, and stay running indefinitely. And cupsd uses a KeepAlive file to tell systemd to start it up on bootup once you enable the web interface, so it should be running right away unless you've added something to manually start/stop cupsd.

In Yakkety (16.10), CUPS behaves as intended upstream, not automatically shutting down when it shares at least one printer or the web interface is active (turned on via "WebInterface Yes" in cupsd.conf). So there this bug should be fixed.

In earlier Ubuntu versions, like Xenial (16.04 LTS), there is a patch which allows for CUPS auto shutdown due to another problem, whgich is fixed in later CUPS versions. This fix needs to get backported so that auto shutdown can be suppressed with active web interface, to match the upstream standard.

Changed in cups (Ubuntu):
status: Confirmed → Fix Released
Changed in cups (Ubuntu Xenial):
status: New → Confirmed
milestone: none → xenial-updates

SRU fix for Xenial is simple. In the CUPS 2.1.3 used there the upstream bug ( is already fixed but it seems that the removal of the workaround patch (auto-shutdown-on-idle-also-with-webinterface-on.patch) got forgotten. So removing this patch seems to be everything which has to get done here.

Andreas Krausz (kukorica) wrote :

I had the same problem in Ubuntu 16.04.1. After some testing I removed all (3) printers and all cups-related packages and reinstalled them. And now (without any additonal changes) all works fine. The only difference: The first time I used a port forwarding to the remote print server like "ssh -L 1631: someuser@somehost" and a local URl "" (because i worked as an unpriviliged user and have a local CUPS daemon on 631). At some cups-Admin-Pages there where error pages like "You have to use". The second time i stopped my local cupsd and called "ssh -L 631: someuser@somehost" as privileged user.

Andreas Krausz (kukorica) wrote :

No. Seems to be the option "-l" which causes systemd to shutdown cupsd and to restart if a print job is available. For applications with pre-checks for available printers or given printer names (for instance with java javax.print.PrintServiceLookup) or with CUPS web Interface on demand this does not work. I changed the option "-l" to "-f" in /lib/systemd/system/cups.service.

Iiro Laiho (iiro) on 2016-11-12
summary: - cups hang after a while
+ CUPS web interface stops responding after a while
tags: added: xenial
Iiro Laiho (iiro) on 2016-11-12
tags: added: regression-release
description: updated
Changed in cups (Ubuntu Xenial):
status: Confirmed → In Progress

Fixed package uploaded to xenial-proposed. Please test the package as soon as it gets available and appropriate test instructions will get posted here. Your feedback is needed in order to make the fix an official update for Xenial.

SRU team: debdiff attached.

Hello dominix, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at . Thank you in advance!

Changed in cups (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed

Note that bug 1642966 which many people observed when updating is not caused by the changes of this SRU (small patch removed from CUPS daemon). So do not worry and apply the workaround shown there, should you also run into a problem with the update. Once your installed CUPS packages being 2.1.3-4ubuntu0.1 please test whether this bug (CUPS web interface stops responding) is fixed. Thank you.

I want to remind everyone subscribed to this bug to please test the fixed package and verify it.

If you get an error during the installation process (see bug 1642966), please run the commands

sudo service cups stop
sudo apt-get install -f
sudo service cups start

in a terminal window to complete the installation (see also comment #5 in bug 1642966). Then test whether this bug is fixed.

To the SRU team: Bug 1642966 cannot be caused by the fix for this bug. The fix is a trivial change in the scheduler, see the debdiff attched to comment #20 of this bug. Bug 1642966 is probably caused by some coincidence which had also broken any other update of the cups package.

dominix (dominix-launchpad) wrote :

fix is on the way. Till now it has not been solved. I am running last 2.1.3-4ubuntu0.1 cups.

I will soon known if it fix the problem. thanks.

dominix (dominix-launchpad) wrote :

it looks good to me, there is 24h on service with no stop on the interfaces.

dominix, thanks. I have marked the SRU as verified now.

tags: added: verification-done
removed: verification-needed
Robie Basak (racb) wrote :

> To the SRU team: Bug 1642966 cannot be caused by the fix for this bug.

I agree. But nevertheless, users may still get errors when upgrading, and won't get errors if we don't release this SRU. So the failures would still be a consequence of releasing this SRU, so I think we should care.

> Bug 1642966 is probably caused by some coincidence which had also broken any other update of the cups package.

Agreed. I did some investigation, and I think it's a race. I added some details in that bug.

So the question is: do we release this SRU in the knowledge that it will cause failures for some users (quite a large number given the numbers affected in bug 1642966), or do we defer until we can have a fix for that bug too?

How important is it that this SRU lands sooner, rather than waiting and bundling a fix for bug 1642966 at the same time?

Robie Basak (racb) wrote :

Another consideration is that the web interface is optional, whereas the failure in bug 1642966 will happen for some proportion of users with a default installation.

To be clear, I'm not saying that we shouldn't release this SRU; just that some consideration and discussion is warranted to consider the trade-off in both directions.

I have same problem.
Ubuntu 16.04.1.
When login in localhost:631, to work with printer's, after some minutes, cups go down, and i see with sudo service cups status, he is inactive.
Problem occur only when logged on web interface, else no.

dominix (dominix-launchpad) wrote :

To give more information on this issue. We are heavily using cups lpd daemon (via inetd) because the machine is used to convert from some old systems, old fashioned printer that do not exists no more, and cups is able to convert this in whatever we want (pcl, pdf, postscript) via its powerfull drivers plugins system.
So cups.lpd might be involved in this issue, because we dont have this issue on system that do not run cups.lpd

Robie Basak (racb) wrote :

For those affected, you can install the version in proposed for the time being (see comment 21), until we decide how to manage this (see comment 27). As I understand it, this is the exact fix that will eventually land in updates.

Thank you Robie for pointing to the fix in comment 21 and for the comment that the final fix should be exactly as that one. Any estimate about when will we see the final fix in updates?

Please note that the delay of publishing the SRU for this bug is cause by bug 1642966. We either need to put out the SRU for that bug first (as it blocks any installation of the CUPS packages) or put out a joint SRU for both bugs.

ThorstenK (tkundoch) on 2017-01-11
Changed in cups (Ubuntu Xenial):
status: Fix Committed → Fix Released
Robie Basak (racb) wrote :

> ** Changed in: cups (Ubuntu Xenial)
> Status: Fix Committed => Fix Released

No, it's not.

Changed in cups (Ubuntu Xenial):
status: Fix Released → Fix Committed
Robie Basak (racb) wrote :

This is still showing up as ready in the pending-sru report, and I'd like it not to in order to prevent accidents. So I'm removing the verification-done tag for now. Please re-add it when this needs reconsidering. It may need re-verifying if we superseded the package in -proposed anyway.

tags: removed: verification-done
ajgreeny (ajg-charlbury) wrote :

Same problem affects my installation of Xubuntu-16.04.1 64bit system.
I have enabled proposed and updated all the many cups packages in that repository and then disabled proposed again.
I think this has solved my problem of cups stopping running but will have to report back after running for some period of time.

ajgreeny (ajg-charlbury) wrote :

An update to my post #36.

I can now confirm that the problem is solved for me; cups no longer stops running after a few minutes, and once again I am able to access ,localhost:631 without the need to start cups running again.

ajgreeny, thank you for testing.

tags: added: verification-done
Robie Basak (racb) wrote :

Please see comments 33 and 35. Any progress on that bug?

tags: removed: verification-done

This is a very serious bug that breaks network printing in certain configurations. To be clear: its not just that cups stops and the web interface is unavailable - it can lead to not being able to print as the print server looks like it is offline to the clients:

D [09/Feb/2017:10:07:02 -0600] [Job 12] Connection error: Transport endpoint is not connected
E [09/Feb/2017:10:07:02 -0600] [Job 12] The printer is not responding.

I was running into this issue on some print servers but not others and in comparing the two cupsd.conf files I found out I can prevent the issue by changing
BrowseLocalProtocols CUPS
BrowseLocalProtocols dnssd

The real problem here is that a feature like this should have a clear and easy way to turn if off completely. I don't ever want cups on a print server stopping to save an insignificant amount of cpu cycles or memory or electricity!

Applying the packages from xenial-proposed does fix it for me, but in my opinion this is a pretty serious issue that needs a quicker fix.

I think the best fix at the moment is the suggestion from Andreas Krausz (kukorica) to change " the option "-l" to "-f" in /lib/systemd/system/cups.service." as it seems that is the only way to turn off this "feature".

Iiro Laiho (iiro) wrote :

launchpad-groovix: Weird. This "feature" shouldn't be active at all when printer sharing is enabled. Did you look the cups log to make sure that it really is the same problem?

And yes, this is a serious issue, but if you read the earlier messages, you see that the fix will cause the bug 1642966 that will result the breakage of some systems. This really should have been fixed before the release of 16.04 xenial (or the patch that caused this maybe shouldn't have been written in first place since it AFAIK solved a thing that was not really a problem), but it's now too late to do anything to the fact that it was not and it's now difficult to fix it since breakage of systems that have a LTS release installed should be avoided.

(iiro) "Did you look the cups log to make sure that it really is the same problem?"

Without any fixes I get these messages about 2 minutes after restarting cups and cupsd is no longer running:

I [09/Feb/2017:04:08:47 -0600] Printer sharing is off and there are no jobs pending, will restart on demand.
I [09/Feb/2017:04:08:47 -0600] Scheduler shutting down normally.

After installing the proposed updates or switching to BrowseLocalProtocols dnssd those messages go away and cupsd stays running and client print jobs don't fail with "Connection error: Transport endpoint is not connected."

(iiro) "but it's now too late to do anything"
Assuming there is absolutely no way to fix bug 1642966, why not switch "-l" to "-f" in /lib/systemd/system/cups.service as an official fix? Is that the only way to completely disable this buggy feature?

Iiro Laiho (iiro) wrote :

launchpad-groovix: I meant it's too late to do anything about that this bug slipped into xenial in first place. Fixing the problem afterwards however should be possible, if little more complicated, sorry for being unclear. The #1642966 probably is fixable and there has been effort to do that to the point there is a PPA that's supposed to contain the fix. However, efforts to make it an official SRU seem to have been stalled for since a month.

I'm also affected by this bug, lots of shared printers (this is the cups server for the network) and cupsd shutting down claiming printer sharing was off.

launchpad-groovix: in 14.04, the only allowed values for BrowseLocalProtocol are All and dnssd, in 16.04 I see All, dnssd, and none. Is CUPS some deprecated setting? My cupsd.conf does not have this set at all, so it's using the default whatever that is.

I'm also affected by this bug, lots of shared printers (this is the cups server for the network) and cupsd shutting down claiming printer sharing was off.

launchpad-groovix: in 14.04, the only allowed values for BrowseLocalProtocol are All and dnssd, in 16.04 I see All, dnssd, and none. Is CUPS some deprecated setting? My cupsd.conf does not have this set at all, so it's using the default whatever that is.

Adding BrowseLocalProtocol dnssd to cupsd.conf did not solve the problem for me, btw.

Switching "-l" to "-f" in /lib/systemd/system/cups.service solved the problem for me. cupsd has now been up for about an hour without shutting down automatically.

Johannes Martin (johannes-martin) wrote: Is CUPS some deprecated setting?

Yes - "BrowseLocalProtocols CUPS" was valid in 12.04 ( what I upgraded from ) but not anymore. If you needed to add a BrowseLocalProtocols line as opposed to switching its value, it seems that this auto-shutdown feature is triggering off that option being present and assigned certain values.

Brian Murray (brian-murray) wrote :

I've let the new version of cups which fixes bug 1642966, into the -proposed pocket for Xenial. My thought was that people would be upgrading from 2.1.3-4 to 2.1.3-4ubuntu0.2 which contains the fix for both bugs.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.