Comment 18 for bug 854490

This is a cups-specific failure, and indicates a real bug in the cups upstart job. While we could treat cups differently in the pam postinst, this would be a workaround as pam *already* checks for whether the service is installed+configured before trying to restart it. So dpkg reports cups is installed, which is why pam tries to restart it, and the fact that it doesn't restart is a cups bug.

> <mvo> tkamppeter: right, at this point libcupsmime1 is unpacked but not configured yet (according to the logs)

However, *cups* was not deconfigured when the new libcupsmime1 was unpacked. If the new libcupsmime1 doesn't work with the old cups, there's a bug in the package dependencies here. It makes no difference if libcupsmime1 is configured vs. unpacked, because configuring libcupsmime1 would not change the missing symbols.

Here's the ldd output from natty cupsd binary on an oneiric system, showing the issue:

$ ldd -d -r cups/usr/sbin/cupsd > /dev/null
undefined symbol: _pwgGetPageSize (cups/usr/sbin/cupsd)
undefined symbol: _pwgDestroy (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetOutputBin (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetType (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetSize (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetInputSlot (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetSource (cups/usr/sbin/cupsd)
undefined symbol: _pwgCreateWithPPD (cups/usr/sbin/cupsd)
undefined symbol: _pwgCreateWithFile (cups/usr/sbin/cupsd)
undefined symbol: _pwgWriteFile (cups/usr/sbin/cupsd)
undefined symbol: _pwgGetMediaType (cups/usr/sbin/cupsd)
$

It looks like these symbols came from libcups2, not from libcupsmime. When these symbols were dropped, libcups *should* have had an soname change upstream. Since it didn't, the next best fix would have been to change the package name. But it's probably too late in the cycle for this now as well, which means that the new libcups2 needs to add a Breaks: against the old cups - and against any other packages which could have been using these symbols (which I assume were considered "private" symbols for cups internal use only).

The other part of this bug is that the cups upstart job is written in such a way that it evades the upstart respawn limit. The default respawn limit in upstart marks a job as failed if it respawns 10 times in 5 seconds; but because the cups job is failing *after* the main process is considered "running" (due to the use of a foregrounded job instead of 'expect daemon' or 'expect fork', which prevents upstart from catching the symbol error when it happens), the post-start script has already been spawned, and the post-start script takes 10 seconds on its own to time out. So the respawns are slow - one every 10 seconds - and upstart never gives up!

(An argument can be made that upstart should have some way of detecting when a job consistently dies before the post-start runs and handle this case the same as hitting the respawn limit if it happens COUNT times in a row.)

Between the foregrounded service process and the polling in the post-start script, this job seems to actually do everything in its power to be slow and fragile. ;) I think we would have better results with an 'expect daemon' job...