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.

-- 
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:
  Triaged

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

Reply via email to