touch-packages team mailing list archive

[Richard Salts <rsalts@xxxxxxxxxx>]

I'm also getting this race condition quite frequently. I believe it's
because the HUP signal is fatal before cups has fully started up and is
catching the signal in its main event loop.

Jan 27 13:51:12 pc008 kernel: [   18.008252] init: cups main process (766) killed by HUP signal
Jan 27 13:51:12 pc008 kernel: [   18.008258] init: cups main process ended, respawning

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1332131

Title:
  avahi-cups-reload Upstart job leads to weird race conditions

Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I'll start out by saying that I cannot _consistently_ reproduce this
  (it is, after all, a race condition), however the fix is trivial and a
  no-op, so I'm filing the bug anyway.

  I ran into the following situation on Ubuntu 14.04:  After booting, it
  was often the case that CUPS would not be running.  CUPS started just
  fine if started by hand, and there were no obvious causes of this in
  the syslog.  However, the times when CUPS was not running, I noticed
  the boot process seemed to be a bit more sluggish than usual.  I
  eventually tracked this down to the avahi-cups-reload job, which
  unconditionally kicks CUPS once avahi has been started, with no regard
  for whether CUPS is actually running.  As soon as I moved that Upstart
  job out of the way, the problems vanished.  My particular issue stems
  from the fact that our site also has another init script that attempts
  to ensure CUPS is running (and restarts it if not), and much of the
  time, this was happening while avahi-cups-reload was attempting to
  reload CUPS.  This resulted in CUPS eventually failing to restart
  (because the post-start script in the CUPS job determined CUPS wasn't
  running, and exited 0.), which Upstart interpreted as success, and
  therefore assumed that CUPS was in fact running.

  I realize this is quite a specific problem, and may well be unique to
  our site, but is there any reason why the the avahi-cups-reload job
  cannot change its condition from:

  start on started avahi-daemon

  to

  start on (started avahi-daemon and started cups)

  which also seems to fix the problem for me, by at least ensuring
  things start in an orderly manner.  (There may well be a subtle
  Upstart bug here too, but this seems like an easy fix.)  See also,
  Launchpad #1251735, where someone else appears to be experiencing a
  variant of this issue, and is also requesting the same fix.

  
  Relevant info:
  avahi-daemon:
    Installed: 0.6.31-4ubuntu1
    Candidate: 0.6.31-4ubuntu1
    Version table:
   *** 0.6.31-4ubuntu1 0
          500 http://mirrors.mit.edu/ubuntu/ trusty/main amd64 Packages
          100 /var/lib/dpkg/status
  cups-daemon:
    Installed: 1.7.2-0ubuntu1
    Candidate: 1.7.2-0ubuntu1
    Version table:
   *** 1.7.2-0ubuntu1 0
          500 http://mirrors.mit.edu/ubuntu/ trusty/main amd64 Packages
          100 /var/lib/dpkg/status
  upstart:
    Installed: 1.12.1-0ubuntu4
    Candidate: 1.12.1-0ubuntu4
    Version table:
   *** 1.12.1-0ubuntu4 0
          500 http://mirrors.mit.edu/ubuntu/ trusty/main amd64 Packages
          100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1332131/+subscriptions