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

[Jonathan Reed]

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

[Launchpad Janitor (janitor)]

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

[Richard Salts (rsalts)]

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