CUPS web interface stops responding after a while

[dominix]

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.

[Impact]

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

[Testcase]

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.

[Regression in Pending SRU page]

* Regression in autopkgtest for c2esp (armhf): test log

This autopkgtest seems always fails :

http://autopkgtest.ubuntu.com/packages/c/c2esp/xenial/armhf

c2esp [xenial/armhf]

Version Triggers Date Duration Result
27-2 cups/2.1.3-4ubuntu0.3 2017-08-23 04:07:44 UTC 2h 50m 13s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.2 2017-08-14 23:31:50 UTC 2h 50m 11s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.2 2017-07-17 20:17:10 UTC 2h 50m 52s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.1 2017-01-20 12:00:41 UTC 2h 49m 29s fail log   artifacts   ♻

Additionally look at Till comment :
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/comments/129

* Regression in autopkgtest for libreoffice (i386): test log

It's a known issue, A regression in the kernel, which breaks libreoffice with java enabled on i386 :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772

... so until this is fixed upstream in the kernel and backported in an ubuntu kernel, I'm afraid the only option is to just ignore the failure.

[Launchpad Janitor (janitor)]

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

[Janne Paalijarvi (jpaalija)]

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.
Status:

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)]

Please follow the instructions of the section "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

[Stephan (meistadieb)]

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)]

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

[Iiro Laiho (iiro)]

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)]

I posted an upstream feature request now to improve the web interface for CUPS running on-demand. See https://github.com/apple/cups/issues/4874.

[Till Kamppeter (till-kamppeter)]

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 https://github.com/apple/cups/issues/4874.

[Till Kamppeter (till-kamppeter)]

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:
  cups.socket
  cups.path
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
till@till-x1carbon:~/printing/cups/bzr/y$

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

[Stephan (meistadieb)]

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.

[Till Kamppeter (till-kamppeter)]

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

Edit the file (with sudo):

/lib/systemd/system/cups.socket

adding a line

ListenStream=631

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

----------
[Unit]
Description=CUPS Scheduler

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=631

[Install]
WantedBy=sockets.target
----------

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

[Till Kamppeter (till-kamppeter)]

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)]

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

[dominix (dominix-launchpad)]

edited /lib/systemd/system/cups.socket

restarted systemd and cups.

waiting for the bug to come back ...

[Stephan (meistadieb)]

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.

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

SRU fix for Xenial is simple. In the CUPS 2.1.3 used there the upstream bug (https://github.com/apple/cups/issues/4755) 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)]

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:127.0.0.1:632 someuser@somehost" and a local URl "127.0.0.1:1631" (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 127.0.0.1:631...". The second time i stopped my local cupsd and called "ssh -L 631:127.0.0.1:631 someuser@somehost" as privileged user.

[Andreas Krausz (kukorica)]

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.

[Till Kamppeter (till-kamppeter)]

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.

[Brian Murray (brian-murray)]

Hello dominix, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.1.3-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed 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 https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

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)]

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)]

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

[Till Kamppeter (till-kamppeter)]

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

[Robie Basak (racb)]

> 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)]

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.

[Alessandro Albanese (alessandroalb2)]

Hi!
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)]

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)]

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.

[Emanuele Olivetti (emanuele-relativita)]

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?

[Till Kamppeter (till-kamppeter)]

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.

[Robie Basak (racb)]

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

No, it's not.

[Robie Basak (racb)]

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.

[ajgreeny (ajg-charlbury)]

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)]

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.

[Till Kamppeter (till-kamppeter)]

ajgreeny, thank you for testing.

[Robie Basak (racb)]

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

[Open Sense Solutions (opensense)]

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
to
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)]

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.

[Open Sense Solutions (opensense)]

(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)]

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.

[Johannes Martin (johannes-martin)]

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.

[Johannes Martin (johannes-martin)]

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.

[Johannes Martin (johannes-martin)]

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.

[Open Sense Solutions (opensense)]

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)]

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.

[Patrick Domack (patrickdk)]

The -proposed 2.1.3-4buntu0.2 fixes this issue for me.

[Robie Basak (racb)]

Bug 1642966 has an upload in xenial-proposed, so we can resume treating this issue as verification-done.

[Robie Basak (racb)]

Unfortunately we still have bug 1642966 which wasn't fixed in 2.1.3-4buntu0.2 as expected, and had to be deleted (see bug 1676380). So this problem still remains. Though we have a fix, we unfortunately can't deploy it without a fix for bug 1642966, since releasing such a fix will cause user errors.

[WhatInThe (whatinthe)]

I just ran into this bug today when I went to use the official cups package for the first time. Or at least I'm pretty sure I did. Google landed me here when I went to search for the output of "service cups status", of which my test system's output looks very similar to the output of the person who opened this ticket and the described behavior is identical to what I'm running into.

This bug makes the cups package for Ubuntu useless for initial configuration from the comfort of a standard desktop - a common enough scenario, IMO. I just can't believe it's taken almost 9 months to still not have a fix pushed out everywhere, but there you have it. Directly running the command being run by the system service (/usr/sbin/cupsd -l) has identical behavior - the software self-terminates after a few minutes of inactivity.

I'm testing the -f option and I'm hoping that it will resolve the issue for me.

[desconocido (bob-lists)]

As it's coming up to the first anniversary of the bug, I thought I would mention that I too have run into it. I normally use Ubuntu 12.04 but I'm trying out Ubuntu 16.04, so my first reaction was that the user interface for CUPS must have changed.

However I got pointed to this page and succeeded with the above mentioned fix of changing line
"ExecStart=/usr/bin/cupsd -l"
to
"ExecStart=/usr/bin/cupsd -f"
in /lib/systemd/system/cups.service
and then
"systemctl daemon-reload"

[teluka (mateusz-p)]

Hi,

Is there any updated to this bug ?

Thanks.

[Łukasz Zemczak (sil2100)]

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

[KWAndi (lst-hoe01)]

It took me a day to find out why our Java App stop printing after a while and cupsd is gone without a notification at all. Could please someone explain why the "cupsd -l" should be useful at all?

Thanks

[Chris Halse Rogers (raof)]

Hello dominix, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.1.3-4ubuntu0.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed 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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[ajgreeny (ajg-charlbury)]

This morning at about 10:30 UTC I updated to cups-2.1.3-4ubuntu0.3 on my 64bit Xubuntu-16.04 using kernel 4.4.0-92 and it has so far not stopped running.
My /etc/cups/cupsd.conf has the "WebInterface Yes" entry but so far no problems at all, though I had no problems with the cups-2.1.3-4ubuntu0.2 version either to which I upgradede with a comment on January 26th.

[Till Kamppeter (till-kamppeter)]

ajgreeny, so it seems that it is fixed for you now. Marking this as verified.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 2.1.3-4ubuntu0.3

---------------
cups (2.1.3-4ubuntu0.3) xenial; urgency=high

  * Adding maintainer script debian/cups-daemon.prerm to deal with situations
    where "old-version" (installed package) prerm script fails. (LP: #1642966).

cups (2.1.3-4ubuntu0.2) xenial; urgency=medium

  * Make cups.path unit be part of the cups.service, since cups.path
    should stop if and when cups.service is stopped. LP: #1642966

cups (2.1.3-4ubuntu0.1) xenial-proposed; urgency=medium

  * Removed auto-shutdown-on-idle-also-with-webinterface-on.patch
    as it causes CUPS to auto-shutdown when web interface support is
    active (LP: #1598300).

 -- Eric Desrochers <email address hidden> Fri, 18 Aug 2017 12:08:28 -0400

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for cups has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[ed20900 (ed20900)]

I am on Kubuntu 17.10 and I am suffering this bug. I do not have the web interface enabled but I have an IPP printer. I have attached the cupsd.conf on my system.
I think this is the relevant part of the file:

# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing Off
BrowseLocalProtocols dnssd

[ed20900 (ed20900)]

I attach the error_log file with debug logging mode. The CUPS notifier closes after a while. That might be the problem. When I open the KDE printer dialog, the D-BUS system bus dumps these messages calling the Notifier method. Opening the printing dialog from LibreOffice writer does not print anything, not even in the session bus:

method call time=1520971612.523540 sender=:1.364 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1520971612.523567 sender=org.freedesktop.DBus -> destination=:1.364 serial=1 reply_serial=1
   string ":1.364"
signal time=1520971612.523580 sender=org.freedesktop.DBus -> destination=(null destination) serial=19 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.364"
   string ""
   string ":1.364"
signal time=1520971612.523598 sender=org.freedesktop.DBus -> destination=:1.364 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.364"
method call time=1520971612.524056 sender=:1.364 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerStarted'"
method call time=1520971612.524213 sender=:1.364 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerStopped'"
method call time=1520971612.524295 sender=:1.364 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerRestarted'"
method call time=1520971612.524399 sender=:1.364 -> destination=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerAudit'"
method call time=1520971612.524514 sender=:1.364 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterAdded'"
method call time=1520971612.524595 sender=:1.364 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterModified'"
method call time=1520971612.524690 sender=:1.364 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterDeleted'"
method call time=1520971612.524760 sender=:1.364 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=o...