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". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1598300 Title: CUPS web interface stops responding after a while Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed 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. [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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1598300/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp