package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

Bug #1642966 reported by Mark Shuttleworth on 2016-11-18
This bug affects 875 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
High
Unassigned
Xenial
High
Eric Desrochers
Yakkety
High
Unassigned
Zesty
High
Unassigned

Bug Description

This concerns only Xenial (16.04)!

[Impact]
* fail to upgrade

[testcase]
Root cause is believed to be reproducible with:

#!/bin/bash
systemctl stop cups.path cups.service
rm /var/cache/cups/org.cups.cupsd
systemctl start cups.path
touch /var/cache/cups/org.cups.cupsd
sleep 1
rm /var/cache/cups/org.cups.cupsd
sleep 1
systemctl stop cups.service
echo $?

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: cups-daemon 2.1.3-4
ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
Uname: Linux 4.4.0-46-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CupsErrorLog:

Date: Fri Nov 18 11:13:15 2016
ErrorMessage: subprocess new pre-removal script returned error exit status 1
InstallationDate: Installed on 2016-05-02 (200 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
Lpstat: device for mallards-officejet-pro-8600: dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
MachineType: Dell Inc. XPS 15 9550
Papersize: a4
PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.1
 apt 1.2.15
SourcePackage: cups
Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/07/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 01.02.00
dmi.board.name: 0N7TVV
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: XPS 15 9550
dmi.sys.vendor: Dell Inc.

[Regression Potential]

Regression risk is low, the fix mitigate cups failing to stop/restart on upgrade. No source code change, just adding a custom pre-removal maintainer script in case of upgrade failure.

[Regression in Pending SRU page]

* Regression in autopkgtest for c2esp (armhf): test log

This autopkgtest seems always fails :

http://autopkgtest.ubuntu.com/packages/c/c2esp/xenial/armhf

c2esp [xenial/armhf]

Version Triggers Date Duration Result
27-2 cups/2.1.3-4ubuntu0.3 2017-08-23 04:07:44 UTC 2h 50m 13s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.2 2017-08-14 23:31:50 UTC 2h 50m 11s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.2 2017-07-17 20:17:10 UTC 2h 50m 52s fail log   artifacts   ♻
27-2 cups/2.1.3-4ubuntu0.1 2017-01-20 12:00:41 UTC 2h 49m 29s fail log   artifacts   ♻

Additionally look at Till comment :
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/comments/129

* Regression in autopkgtest for libreoffice (i386): test log

It's a known issue, A regression in the kernel, which breaks libreoffice with java enabled on i386 :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772

... so until this is fixed upstream in the kernel and backported in an ubuntu kernel, I'm afraid the only option is to just ignore the failure.

[Other Info]

* The patch is joint effort between xnox and slashd.

Mark Shuttleworth (sabdfl) wrote :
Till Kamppeter (till-kamppeter) wrote :

This is not caused by xenial-proposed. xenial-proposed is version 2.1.3-4ubuntu0.1 and I got tons of reports on version 2.1.3-4 which is before xenial-proposed. So the origin must be somewhere else.

Till Kamppeter (till-kamppeter) wrote :

The SRU for Xenial (bug 1598300) is a one-line patch removal on the CUPS daemon, the problem observed here and in many other reports is on the shutdown of the old CUPS daemon. So it seems that some independent change, in a not yet known package, causes problems shutting down CUPS, but the problem is revealed by the fact that an new CUPS version (2.1.3-4ubuntu0.1 from the SRU bug 1598300) got uploaded and so all users who have activated xenial-proposed get a CUPS update triggering this problem.

Launchpad Janitor (janitor) wrote :

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

Changed in cups (Ubuntu):
status: New → Confirmed
Till Kamppeter (till-kamppeter) wrote :

For everyone who is reading here as his report is added as a duplicate of this one:

First, see my comment #2 and comment #3.

In one of the duplicates a user reported that he could solve the problem (get new CUPS package installed) doing the following commands in a terminal window:

sudo service cups stop
sudo apt-get install -f
sudo service cups start

The reason why CUPS fails to shut down during the update (the CUPS daemon of the old CUPS package 2.1.3-4) is not known yet. I cannot reproduce it.

So if someone can somehow reproduce it, please attach the CUPS error_log in debug mode.

Independent of this, please everyone who has suffered this problem TODAY, please attach your CUPS error_log TODAY. Who suffered the problem yesterday, please attach error_log and error_log.1.

error_log and error_log.1 are in the /var/log/cups/ directory.

Changed in cups (Ubuntu):
status: Confirmed → Incomplete
Videonauth (videonauth) wrote :

Affected by this. Attached my error_log but I don't think you will be able to read much out of it as it is only 3 lines. Your fix suggestion however worked out for me.

Laurie (ljl069) wrote :

Adding my error_log here. The suggested fix also worked for me. Odd thing is the date/time on the error_log is 10/21/16 even though I got the error this morning...

x (xtxrx) wrote :

I am getting same error only my kernel is newer

Linux TIS-PC 4.4.0-49-generic #70-Ubuntu SMP Fri Nov 11 16:40:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Julien (julienmbpe) wrote :

I can't help : error_log is empty and error_log.1 is from 14 Nov 2016

Julien (julienmbpe) wrote :

Tried #5 but :
sudo service cups start
Job for cups.socket failed. See "systemctl status cups.socket" and "journalctl -xe" for details.

systemctl status cups.socket
● cups.socket - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.socket; enabled; vendor preset: enab
   Active: inactive (dead) since sam. 2016-11-19 17:16:13 CET; 6min ago
   Listen: /var/run/cups/cups.sock (Stream)

nov. 19 10:41:20 julien-P55-UD6 systemd[1]: Listening on CUPS Scheduler.
nov. 19 17:16:13 julien-P55-UD6 systemd[1]: Closed CUPS Scheduler.
nov. 19 17:21:26 julien-P55-UD6 systemd[1]: cups.socket: Socket service cups.ser
nov. 19 17:21:26 julien-P55-UD6 systemd[1]: Failed to listen on CUPS Scheduler.
lines 1-9/9 (END)

journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'horloge système a été modifiée et positionnée à REALTIME microsecondes
-- après le 1er janvier 1970.
nov. 19 17:22:48 julien-P55-UD6 systemd[1]: snapd.refresh.timer: Adding 4h 7min
nov. 19 17:22:48 julien-P55-UD6 systemd[1]: apt-daily.timer: Adding 7h 5min 1.52
nov. 19 17:23:21 julien-P55-UD6 systemd[1]: Time has been changed
-- Subject: Changement d'heure
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'horloge système a été modifiée et positionnée à REALTIME microsecondes
-- après le 1er janvier 1970.
nov. 19 17:23:21 julien-P55-UD6 systemd[1228]: Time has been changed
-- Subject: Changement d'heure
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'horloge système a été modifiée et positionnée à REALTIME microsecondes
-- après le 1er janvier 1970.
nov. 19 17:23:21 julien-P55-UD6 systemd[1]: snapd.refresh.timer: Adding 3h 49min
nov. 19 17:23:21 julien-P55-UD6 systemd[1]: apt-daily.timer: Adding 8h 31min 51.
lines 3601-3623/3623 (END)

Stephan Springer (geryon) wrote :

Same problem here:

Preparing to unpack .../cups-daemon_2.1.3-4ubuntu0.1_amd64.deb ...
Job for cups.service canceled.
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Job for cups.service canceled.
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: error processing archive /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.1_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
[…]
Errors were encountered while processing:
 /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package. Trying to recover:
[…]

After trying the upgrade a second time, it worked:

Unpacking cups-daemon (2.1.3-4ubuntu0.1) over (2.1.3-4) ...
Preparing to unpack .../libisc-export160_1%3a9.10.3.dfsg.P4-8ubuntu1.3_amd64.deb ...
[…]
Setting up cups-daemon (2.1.3-4ubuntu0.1) ...
Setting up cups-core-drivers (2.1.3-4ubuntu0.1) ...
Setting up cups (2.1.3-4ubuntu0.1) ...
Updating PPD files for cups ...

But /var/log/cups/error_log is empty.

Changed in cups (Ubuntu):
status: Incomplete → Confirmed
Sam_ (and-sam) wrote :

After a new installation backports were enabled, that shouldn't be the case, thanks for the hint.

Vincent Gerris (vgerris) wrote :

I noticed a few days back after a failed update that I had cups as a broken package.
I uninstalled and some other packages were removed, then I reinstalled.
That seemed to work. I don't know what I lost and while reporting I got a notification that my conf file was edited.
Can't remember ever changing anything.

Stephan Springer (geryon) wrote :

Same here, apport incorrectly complained that /etc/default/cups was modified. I never touched that one. The content is:

# Cups configure options

# LOAD_LP_MODULE: enable/disable to load "lp" parallel printer driver module
# LOAD_LP_MODULE has migrated to /etc/modules-load.d/cups-filters.conf
# LOAD_LP_MODULE=yes

Using easytether I had a few Hiccup's had to uninstall samba

On Nov 20, 2016 5:30 PM, "Vincent Gerris" <email address hidden>
wrote:

> I noticed a few days back after a failed update that I had cups as a
> broken package.
> I uninstalled and some other packages were removed, then I reinstalled.
> That seemed to work. I don't know what I lost and while reporting I got a
> notification that my conf file was edited.
> Can't remember ever changing anything.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1642796).
> https://bugs.launchpad.net/bugs/1642966
>
> Title:
> package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
> pre-removal script returned error exit status 1
>
> Status in cups package in Ubuntu:
> Confirmed
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> ProblemType: Package
> DistroRelease: Ubuntu 16.04
> Package: cups-daemon 2.1.3-4
> ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
> Uname: Linux 4.4.0-46-generic x86_64
> NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
> ApportVersion: 2.20.1-0ubuntu2.1
> Architecture: amd64
> CupsErrorLog:
>
> Date: Fri Nov 18 11:13:15 2016
> ErrorMessage: subprocess new pre-removal script returned error exit
> status 1
> InstallationDate: Installed on 2016-05-02 (200 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
> (20160420.1)
> Lpstat: device for mallards-officejet-pro-8600: dnssd://Officejet%20Pro%
> 208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-
> 1f08-abcd-d89d67d63461
> MachineType: Dell Inc. XPS 15 9550
> Papersize: a4
> PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups
> 3.16.3
> ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed
> root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash
> vt.handoff=7
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed
> root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash
> vt.handoff=7
> RelatedPackageVersions:
> dpkg 1.18.4ubuntu1.1
> apt 1.2.15
> SourcePackage: cups
> Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess
> new pre-removal script returned error exit status 1
> UpgradeStatus: No upgrade log present (probably fresh install)
> dmi.bios.date: 04/07/2016
> dmi.bios.vendor: Dell Inc.
> dmi.bios.version: 01.02.00
> dmi.board.name: 0N7TVV
> dmi.board.vendor: Dell Inc.
> dmi.board.version: A00
> dmi.chassis.type: 9
> dmi.chassis.vendor: Dell Inc.
> dmi.modalias: dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:
> pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
> dmi.product.name: XPS 15 9550
> dmi.sys.vendor: Dell Inc.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+subscriptions
>

so is there any thing i can do to make things better, or should i think it is not a threat

Roger Joness (nidge81146) wrote :

Should I as just a user ignore this problem? Don't understand what is going
on really.

On Thu, 24 Nov 2016 at 04:45, Isiramen Akeeminemen <
<email address hidden>> wrote:

> so is there any thing i can do to make things better, or should i think
> it is not a threat
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1643196).
> https://bugs.launchpad.net/bugs/1642966
>
> Title:
> package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
> pre-removal script returned error exit status 1
>
> Status in cups package in Ubuntu:
> Confirmed
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> ProblemType: Package
> DistroRelease: Ubuntu 16.04
> Package: cups-daemon 2.1.3-4
> ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
> Uname: Linux 4.4.0-46-generic x86_64
> NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
> ApportVersion: 2.20.1-0ubuntu2.1
> Architecture: amd64
> CupsErrorLog:
>
> Date: Fri Nov 18 11:13:15 2016
> ErrorMessage: subprocess new pre-removal script returned error exit
> status 1
> InstallationDate: Installed on 2016-05-02 (200 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
> (20160420.1)
> Lpstat: device for mallards-officejet-pro-8600:
> dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
> MachineType: Dell Inc. XPS 15 9550
> Papersize: a4
> PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups
> 3.16.3
> ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed
> root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed
> root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
> RelatedPackageVersions:
> dpkg 1.18.4ubuntu1.1
> apt 1.2.15
> SourcePackage: cups
> Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess
> new pre-removal script returned error exit status 1
> UpgradeStatus: No upgrade log present (probably fresh install)
> dmi.bios.date: 04/07/2016
> dmi.bios.vendor: Dell Inc.
> dmi.bios.version: 01.02.00
> dmi.board.name: 0N7TVV
> dmi.board.vendor: Dell Inc.
> dmi.board.version: A00
> dmi.chassis.type: 9
> dmi.chassis.vendor: Dell Inc.
> dmi.modalias:
> dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
> dmi.product.name: XPS 15 9550
> dmi.sys.vendor: Dell Inc.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+subscriptions
>
--
Sent from my IPad

Changed in cups (Ubuntu):
importance: Undecided → High
Robie Basak (racb) wrote :

I think this might be caused by an interesting interaction between systemd, debhelper and the CUPS scheduler.

I can reproduce a very similar error with the following. I think (though am not sure) that this is related to the root cause. On a fresh Xenial system:

sudo apt-get update && sudo apt-get -y install cups
sudo -i
systemctl stop cups.service
sleep 4
touch /var/cache/cups/org.cups.cupsd
sleep 4
sudo rm /var/cache/cups/org.cups.cupsd
sleep 4
systemctl stop cups.service

(the sleeps are to avoid any unknown, additional and unintentional race conditions)

This results in an exit status of 1 and the message "Job for cups.service canceled." which matches the error that reporters have been seeing.

In other words, if cups.service is started via cups.path, that cause is removed, and then we request a manual stop of cups.service, then systemd refuses to stop the service the first time (a retry always succeeds for me).

In cups-daemon.prerm, debhelper has added "deb-systemd-invoke stop cups.path" followed by "invoke-rc.d cups stop || exit $?". I believe the second invocation is ultimately equivalent to "systemctl stop cups.service" and fails the same way as in my example, causing the prerm to exit 1, causing the dpkg failure reported.

I'm not sure of the intended logic for /lib/systemd/system/cups.path here. AFAICT, it exists because when using CUPS with launchd, the CUPS daemon leaves the file in place as long as it doesn't want to be terminated, and removes it when it wants to be terminated before it exits anyway. Is this because launchd kills daemons itself unless the keepalive file exists?

With systemd, I can't find any documentation that suggests that systemd ever intends to automatically kill a socket activated daemon. AFAICT, it's entirely up to the daemon when it chooses to exit. So there appears to be no need for cupsd to maintain /var/cache/cups/org.cups.cupsd when running under systemd.

As configured right now, systemd will also start cupsd if /var/cache/cups/org.cups.cupsd is created while cupsd is not running. I can't find anything that might use this function. So either this is an accidental side-effect that is not needed, or I have missed some other path that does need this.

systemd talks about CUPS in a blog post that is relevant: http://0pointer.de/blog/projects/socket-activation2.html. Note that this only sets up a path unit for /var/spool/cups, not any kind of keepalive file for cupsd.

Robie Basak (racb) wrote :

I'm getting some stranger behaviour on Zesty.

1) cups.path doesn't seem to be started until after reboot.
2) I can't reliably reproduce my example case. After the second stop, cups.service is claimed to have been stopped successfully, but a subsequent call to "systemctl status cups.service" shows it as still running.
3) I have seen the failure case from my example in my testing on Zesty, after fiddling with combinations of commands from my example, but I don't have steps to get there.

Robie Basak (racb) wrote :

I can reproduce my original example on Xenial on a different machine, and now I see that it is a race. Whether I drop the sleeps or not, it sometimes gives me "Job for cups.service canceled." and sometimes:

Warning: Stopping cups.service, but it can still be activated by:
  cups.path

Robie, thanks for the investigations. I have looked into what the file /var/cache/cups/org.cups.cupsd (CUPS calls it "keepalive" file) is good for and what CUPS does with it. The file is created by the CUPS daemon cupsd when it needs to keep running, having active jobs, being in the course of a reload, having the web interface active or sharing printers, otherwise the file is removed. CUPS updates presence/no presence on start-up and shutdown of the daemon and it does exactly the same in both cases, so it can remain present after shutdown, depending on CUPS' configuration. CUPS never reads this file (or checks its presence), meaning that it is purely for advising external processes.

So for me it looks like that there is a certain system service manager (what one usually runs as PID 1 under Linux) which checks for the presence of keepalive files and decides based on this which daemons to kill and which to keep running.

I do not know everything about systemd. Does systemd care about keepalive files?

The CUPS upstream *.path makes cupsd being triggered by creating the file, but only if the file is not there already. What is this good for?

Does this *.path also take down cupsd if one removes the keepalive file or is systemd supposed to do so? For me cupsd does not get stopped by that.

And why does shutdown of CUPS fail after removing the keepalive file (with "Job for cups.service canceled.")? As CUPS does not care about it, systemd seems to depend on it. And what in the prerm script of the CUPS Debian package deletes the keepalive file?

Can everyone suffering this problem please attach his /etc/cups/cupsd.conf file? Please also post the output of the commands:

lpstat -v
lpstat -o

Pierluigi70 (oriente70libero) wrote :
Download full text (5.1 KiB)

Ok Thanks so much
I try to do it

Il 30/nov/2016 19:01, "Robie Basak" <email address hidden> ha scritto:

> I think this might be caused by an interesting interaction between
> systemd, debhelper and the CUPS scheduler.
>
> I can reproduce a very similar error with the following. I think (though
> am not sure) that this is related to the root cause. On a fresh Xenial
> system:
>
> sudo apt-get update && sudo apt-get -y install cups
> sudo -i
> systemctl stop cups.service
> sleep 4
> touch /var/cache/cups/org.cups.cupsd
> sleep 4
> sudo rm /var/cache/cups/org.cups.cupsd
> sleep 4
> systemctl stop cups.service
>
> (the sleeps are to avoid any unknown, additional and unintentional race
> conditions)
>
> This results in an exit status of 1 and the message "Job for
> cups.service canceled." which matches the error that reporters have been
> seeing.
>
> In other words, if cups.service is started via cups.path, that cause is
> removed, and then we request a manual stop of cups.service, then systemd
> refuses to stop the service the first time (a retry always succeeds for
> me).
>
> In cups-daemon.prerm, debhelper has added "deb-systemd-invoke stop
> cups.path" followed by "invoke-rc.d cups stop || exit $?". I believe the
> second invocation is ultimately equivalent to "systemctl stop
> cups.service" and fails the same way as in my example, causing the prerm
> to exit 1, causing the dpkg failure reported.
>
> I'm not sure of the intended logic for /lib/systemd/system/cups.path
> here. AFAICT, it exists because when using CUPS with launchd, the CUPS
> daemon leaves the file in place as long as it doesn't want to be
> terminated, and removes it when it wants to be terminated before it
> exits anyway. Is this because launchd kills daemons itself unless the
> keepalive file exists?
>
> With systemd, I can't find any documentation that suggests that systemd
> ever intends to automatically kill a socket activated daemon. AFAICT,
> it's entirely up to the daemon when it chooses to exit. So there appears
> to be no need for cupsd to maintain /var/cache/cups/org.cups.cupsd when
> running under systemd.
>
> As configured right now, systemd will also start cupsd if
> /var/cache/cups/org.cups.cupsd is created while cupsd is not running. I
> can't find anything that might use this function. So either this is an
> accidental side-effect that is not needed, or I have missed some other
> path that does need this.
>
> systemd talks about CUPS in a blog post that is relevant:
> http://0pointer.de/blog/projects/socket-activation2.html. Note that this
> only sets up a path unit for /var/spool/cups, not any kind of keepalive
> file for cupsd.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1644526).
> https://bugs.launchpad.net/bugs/1642966
>
> Title:
> package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
> pre-removal script returned error exit status 1
>
> Status in cups package in Ubuntu:
> Confirmed
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> ProblemType: Package
> DistroRelease: Ubuntu 16.04
> Package: cups-daemon 2....

Read more...

Anthony Ledford (tony-csu0kx) wrote :

Terminal output:

lpstat -v
device for Brother-HL-2270DW-series: dnssd://Brother%20HL-2270DW%20series._pdl-datastream._tcp.local/

lpstat -o outputs nothing, there are no jobs in queue

cupsd.conf attached.

Robie Basak (racb) wrote :

@Till

> Robie, thanks for the investigations. I have looked into what the file /var/cache/cups/org.cups.cupsd (CUPS calls it "keepalive" file) is good for and what CUPS does with it. The file is created by the CUPS daemon cupsd when it needs to keep running, having active jobs, being in the course of a reload, having the web interface active or sharing printers, otherwise the file is removed. CUPS updates presence/no presence on start-up and shutdown of the daemon and it does exactly the same in both cases, so it can remain present after shutdown, depending on CUPS' configuration. CUPS never reads this file (or checks its presence), meaning that it is purely for advising external processes.

> So for me it looks like that there is a certain system service manager (what one usually runs as PID 1 under Linux) which checks for the presence of keepalive files and decides based on this which daemons to kill and which to keep running.

Right - I believe this is launchd (under OS X).

I do not know everything about systemd. Does systemd care about keepalive files?

> AFAIK, no, not at all. You can configure systemd to start cupsd when a named file appears ("systemd.path"). I can't find anything documented about systemd stopping any service ever. The source that handles "systemd.path" doesn't ever appear to stop a service. Upstream appears to have configured this in their supplied systemd units, but I believe it may be unnecessary.

> The CUPS upstream *.path makes cupsd being triggered by creating the file, but only if the file is not there already. What is this good for?

Exactly :-)

AFAICT, it serves no purpose.

> Does this *.path also take down cupsd if one removes the keepalive file or is systemd supposed to do so? For me cupsd does not get stopped by that.

AFAICT, removing the file isn't supposed to cause any action. Nothing should happen when the file is removed, and nothing does happen (apart from perhaps some state change within systemd, or some timing delay helping us trigger the race).

> And why does shutdown of CUPS fail after removing the keepalive file (with "Job for cups.service canceled.")? As CUPS does not care about it, systemd seems to depend on it.

This I'm not sure about. It may be a systemd race or bug. I pinged pitti to take a look, but he was busy. But if we definitely don't need cups.path, perhaps removing it will fix the problem (whether that's working around a bug in systemd or in the current CUPS systemd arrangements I don't know).

> And what in the prerm script of the CUPS Debian package deletes the keepalive file?

Nothing, AFAICT. It's only cupsd that deletes it on exit. The prerm stops cups.path, then stops cups.service. I don't know that my example above reproduces the root cause. But it does seem to reproduce a race that produces the same symptoms that seems to fit reasonably well.

Robie Basak (racb) wrote :

Sorry, I screwed up my quoting a little there. Hopefully it's still comprehensible.

Adding systemd task, as cupsd itself shuts down correctly independent of the presence or absence of the keepalive file. There must be some problem in systemd's shutdown process.

For the systemd experts/maintainers: See comment #18 and comment #21 for a reproducer and some explanation of what is happening.

Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Robie Basak (racb) wrote :

> There must be some problem in systemd's shutdown process.

Either this, or it is expected behaviour and cups-daemon's supplied systemd units are somehow wrong. Or it could be in debhelper. I'm not sure which.

Added also an init-system-helpers task, as this package contains the deb-systemd-invoke debhelper.

Launchpad Janitor (janitor) wrote :

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

Changed in init-system-helpers (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

I didn't reproduce this yet, answering Till's questions first.

> Does systemd care about keepalive files?

No, there is no such concept. You can certainly build such a thing using path units and others, but no Linux init system kills processes willy-nilly from the outside (except on shutdown, of course) -- daemons either have a built-in timeout and quit themselves, or have to be stopped explicitly.

> The CUPS upstream *.path makes cupsd being triggered by creating the file, but only if the file is not there already. What is this good for?

I have no idea. I haven't printed anything in years (I don't even have a printer), and that file exists, thus that .path unit always gets activated and starts cupsd.service even though I have no need for it. Does that ever actually get cleaned up?

Also, such "keepalive" stamps should *always* be in /run -- it makes no sense to put them on the file system in /var where they are persistent across reboot.

> Does this *.path also take down cupsd if one removes the keepalive file.

No, it doesn't (at least not in the way that path unit is written). This also doesn't make much sense, TBH -- you can never know from the outside if a daemon is still required to run, so you always need the daemon itself to make that decision. Instead of creating/removing keepalive files it could just stop itself, which is structurally a lot simpler.

> And why does shutdown of CUPS fail after removing the keepalive file (with "Job for cups.service canceled.")?

It sounds like cups.service gets stopped, but around the same time something tries to start it again, possibly via either cups.path or cups.socket. In generally, if you need to prevent a service from restarting, you need to first stop all "auto-activating" units (path, socket, timer) as well, and before stopping the .service.

> what in the prerm script of the CUPS Debian package deletes the keepalive file?

The maintainer scripts don't, and I'm not at all convinced that anything is actually removing it (see above). Maybe cupsd is supposed to clean it on shutdown, but this doesn't happen sometimes?

So ISTM that the current cups.path serves no real purpose and apparently just gets in the way. I think what *would* make sense is to have a path unit that starts cups at boot if there are pending print jobs, e. g. something like "DirectoryNotEmpty=/var/spool/cups".

Martin Pitt (pitti) wrote :

FTR:
-r-------- 1 root root 0 Feb 11 2015 /var/cache/cups/org.cups.cupsd

Robie Basak (racb) wrote :

On Fri, Dec 02, 2016 at 10:19:24AM -0000, Martin Pitt wrote:
> It sounds like cups.service gets stopped, but around the same time
> something tries to start it again, possibly via either cups.path or
> cups.socket. In generally, if you need to prevent a service from
> restarting, you need to first stop all "auto-activating" units (path,
> socket, timer) as well, and before stopping the .service.

In my failure example, I wonder if cupsd itself is triggering systemd to
start it as it shuts down (by creating the keepalive file briefly after
receiving the shutdown signal but before quitting).

However, in the real world failure case, cups.path is stopped before
cups.service, so I don't think that can be it.

Martin Pitt (pitti) wrote :

I tried this on zesty, and in comment #20 Robie tried on xenial, and we both get:

> Warning: Stopping cups.service, but it can still be activated by:
> cups.path

(I additionally get cups.socket there too). Thus:

> However, in the real world failure case, cups.path is stopped before
> cups.service, so I don't think that can be it.

This actually is not the case in zesty (haven't checked yakkety) any more -- cups-daemon.prerm does not stop cups.path any more. Thus I wonder what happens in xenial, as there clearly is a stop.

I cannot yet reproduce this in a clean xenial VM with either robie's recipe from comment #18 or a repeated "apt-get install --reinstall cups-daemon". I also tried with tight races like

  touch /var/cache/cups/org.cups.cupsd; systemctl stop cups.service

(and also swapping around the commands).

For someone who can reproduce this, can you please do the following:

  sudo systemd-analyze set-log-level debug
  [... steps to reproduce the bug ...]
  sudo systemd-analyze set-log-level info
  sudo journalctl -b > /tmp/journal.txt

and attach /tmp/journal.txt here?

Changed in cups (Ubuntu):
status: Confirmed → Incomplete
Robie Basak (racb) wrote :

Using my example, I did:

systemd-analyze set-log-level debug
systemctl stop cups.service
touch /var/cache/cups/org.cups.cupsd
sudo rm /var/cache/cups/org.cups.cupsd
systemctl stop cups.service
systemd-analyze set-log-level info
journalctl -b > /tmp/journal.txt

And journal.txt attached. Note that I had to do this a number of times to reproduce the race. The last time was the time that I got "Job for cups.service canceled.". There were one or two other occurrences that I missed.

Interestingly, "cups.service: Start request repeated too quickly." appears on a successful run. Where I got the "canceled" error, nothing unusual is logged.

Changed in cups (Ubuntu):
status: Incomplete → Confirmed

I did the following:

till@till-x1carbon:~$ sudo -i
[sudo] password for till:
root@till-x1carbon:~# systemd-analyze set-log-level debug
root@till-x1carbon:~# systemctl stop cups.service
Warning: Stopping cups.service, but it can still be activated by:
  cups.path
  cups.socket
root@till-x1carbon:~# sleep 4
root@till-x1carbon:~# touch /var/cache/cups/org.cups.cupsd
root@till-x1carbon:~# sleep 4
root@till-x1carbon:~# sudo rm /var/cache/cups/org.cups.cupsd
root@till-x1carbon:~# sleep 4
root@till-x1carbon:~# systemctl stop cups.service
Job for cups.service canceled.
root@till-x1carbon:~# systemd-analyze set-log-level info
root@till-x1carbon:~# journalctl -b > /tmp/journal.txt
root@till-x1carbon:~#

And as you see, I could reproduce the error ("Job for cups.service canceled.").

journal.txt attached.

Martin Pitt (pitti) wrote :

> Interestingly, "cups.service: Start request repeated too quickly." appears on a successful run.

This would usually happen if you try things in a loop, (5 or more restarts in 10s); run "systemctl reset-failed <unit>" in between to reset the counter.

The journal shows an obvious loop, and at that point the log doesn't tell much because you are running into the restart limit.

And could you extend your reproducer to run

  journalctl --quiet --lines=0 --show-cursor

and the beginning, and at the end

  journalctl -c "s=... (cursor obtained from above)"

so that we only see the bits that happen during one run, not the whole noise around it?

What could auto-start CUPS is cups-browsed for example, but with

Requires=cups.service

in

/lib/systemd/system/cups-browsed.service

the shutdown of CUPS should shutdown cups-browsed first.

Also important is that first both the .path and .socket get shut down first, to avoid an auto-start of CUPS when .service gets shut down.

The cups.pathy file comes from CUPS upstream. One should report a bug about that the file (and the keepalive file) do not make sense and a cups.path starting CUPS whenthere are pending jobs would be a much better idea.

Changed in cups (Ubuntu):
status: Confirmed → Invalid
Changed in init-system-helpers (Ubuntu):
importance: Undecided → High
Changed in systemd (Ubuntu):
importance: Undecided → High
Martin Pitt (pitti) on 2016-12-05
Changed in cups (Ubuntu):
status: Invalid → Confirmed
tags: removed: need-duplicate-check
Changed in systemd (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-16.12
description: updated
Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Changed in init-system-helpers (Ubuntu):
status: Confirmed → Invalid
Changed in cups (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-16.12
no longer affects: init-system-helpers (Ubuntu)
no longer affects: systemd (Ubuntu)
no longer affects: init-system-helpers (Ubuntu Zesty)
no longer affects: init-system-helpers (Ubuntu Yakkety)
no longer affects: init-system-helpers (Ubuntu Xenial)
no longer affects: systemd (Ubuntu Xenial)
no longer affects: systemd (Ubuntu Yakkety)
no longer affects: systemd (Ubuntu Zesty)
Changed in cups (Ubuntu Xenial):
status: New → Triaged
Changed in cups (Ubuntu Yakkety):
status: New → Triaged
Changed in cups (Ubuntu Zesty):
status: Confirmed → Triaged
Changed in cups (Ubuntu Yakkety):
importance: Undecided → High
Changed in cups (Ubuntu Xenial):
importance: Undecided → High
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-16.04.2
Changed in cups (Ubuntu Yakkety):
milestone: none → yakkety-updates
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in cups (Ubuntu Zesty):
milestone: ubuntu-16.12 → ubuntu-17.01
Changed in cups (Ubuntu Zesty):
milestone: ubuntu-17.01 → ubuntu-17.02
Iiro Laiho (iiro) on 2017-02-11
Changed in cups (Ubuntu Zesty):
assignee: Dimitri John Ledkov (xnox) → nobody
status: Triaged → Fix Released
Iiro Laiho (iiro) on 2017-02-11
tags: added: patch
Changed in cups (Ubuntu Yakkety):
status: Triaged → Fix Committed
tags: added: verification-needed
Changed in cups (Ubuntu Xenial):
status: Triaged → Fix Committed
Iiro Laiho (iiro) on 2017-03-09
tags: added: verification-done
removed: verification-needed
Robie Basak (racb) on 2017-03-27
tags: added: verification-done-xenial
removed: verification-done
Changed in cups (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in cups (Ubuntu Yakkety):
assignee: Dimitri John Ledkov (xnox) → nobody
Changed in cups (Ubuntu Xenial):
assignee: Dimitri John Ledkov (xnox) → nobody
Changed in cups (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Robie Basak (racb) on 2017-03-27
Changed in cups (Ubuntu Xenial):
status: Fix Released → Triaged
description: updated
Changed in cups (Ubuntu Xenial):
status: Triaged → Confirmed
Changed in cups (Ubuntu Xenial):
status: Confirmed → Triaged
54 comments hidden view all 134 comments
Iiro Laiho (iiro) wrote :

So, what would be a reliable way to reproduce the problem?

Should the following sequence always trigger this issue:

- Do a clean Ubuntu install
- Install updates
- Enable -proposed
- Update cups-daemon?

Steve Klicek (steveklicek) wrote :

The bug appeared only once as Till Kamppeter wrote on 2017-03-28 after updating cups-daemon on a clean Ubuntu installation. Until there all of the proposed updates were made. The printers installed on the system do their work.

Iiro Laiho (iiro) wrote :

till-kamppeter, what do you mean by "restarting systemd"? Does it mean that we could try adding something like this to the postinstall script:

"if dpkg --compare-versions "$2" lt-nl "2.1.3-4ubuntu0.2"; then
    systemctl daemon-reexec
fi"?

Does it belong inside of the "if [ "$1" = configure ]" condition or outside?

Iiro Laiho (iiro) wrote :

I have concluded that this problem only appears if the -proposed package has never been installed AND cupsd is running.

So, the way to reproduce this is:

- Do a clean Ubuntu install
- Install updates
- Enable -proposed
- Make sure that cupsd is running
- Update cups-daemon.

When I do this, the CUPS service gets in a weird state in which it can't be successfully stopped with systemctl nor invoke-rc.d. I have tried reloading systemd configuration, stopping and disabling cups.path, but the only thing that I have used with success to make the init system function again is to manually run "killall cupsd".

Iiro Laiho (iiro) wrote :

Sorry, the "Make sure that cupsd is running" part should apparently be "Make sure there is a stuck job in cups"

Iiro Laiho (iiro) wrote :

The root cause of this problem is probably that the "invoke-rc.d cups stop" command fails on Xenial if there are jobs in queue. The dpkg preremoval script runs that command and thus the upgrade procedure fails. In the newer Ubuntu versions the command executes flawlessly.

Until that problem is fixed in some way or another in Xenial, it isn't probably possible at all to safely publish any updates to cups-daemon, not even critical zero-day security patches.

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

Manfred Hesse (mandres11) wrote :

Wie kann ich als Anfänger den Schaden beheben?

Eric Desrochers (slashd) wrote :

Hi,

After some discussions with xnox and tkamppeter, here's a summary of the situations for this particular bug.

The foundation team know how to fix this issue, but so far they do not have a broken system to test the fixes on, before uploading, thus not reproducer.

We basically needs someone who runs into the problem and did not apply any workaround or someone who can re-create the conditions needed to reproduce the bug for Xenial and then try the update.

I know it might be extremely difficult to reproduce, but this will be needed for us to concludes things and SRU the proper fix.

If you have a reproducer, please provide the steps in detail.

Regards,
Eric

Suggested fix (and AFAIR it is the one working in Yakkety and Zesty) is in comment #52. Reproducers are in comment #18, comment #21, and comment #37. I do not know why this does not work in Xenial.

Comment #98 seems to be a good recipe to reproduce the actual problem here. Also have a look at the comments afterwards.

Eric Desrochers (slashd) wrote :

I tried to reproduce on my side using the reproducer explain in comment #98 and #99, and I couldn't reproduce it.

@xnox

Since foundation know how to fix it, can we try to fixing it blind for now ? Upload in xenial-proposed, and wait for users feedbacks ?

If something goes wrong, we can still drop the code and set the bug to "verification-xenial-failed".

Thoughts ?

- Eric

Iiro Laiho (iiro) wrote :

@slashd, Maybe something has changed in systemd or something? I'll check it out sometime when I have time.

Did you make a clean install? How did you ensure that the job was stuck in the queue? I remember that adding a socket:// printer with an invalid address did the trick.

Eric Desrochers (slashd) wrote :

@iiro, yes I tried your reproducer a couple of time without success.

- Clean Ubuntu install
- Install updates
- Enable -proposed
- Make sure that cupsd is running with stuck job using an invalid printer IP

--
▼ ID ▼ Name User Size Pages State Control
Bug1642966-1 Unknown Withheld 1k 3 processing since
"The printer is not responding."
--

- Update cups-daemon.

and nothing went wrong on my side.

Am I missing something ?

Iiro Laiho (iiro) wrote :

Nope, the problem is still present in -proposed. Here's a more detailed procedure of reproducing the bug:

- Do a clean Ubuntu install. I installed Ubuntu from the 16.04.3 desktop media to a VirtualBox VM.
- Do a "apt update && apt upgrade" as usual
- Per the instructions from <https://wiki.ubuntu.com/Testing/EnableProposed>, do what is told in the "Selective upgrading from -proposed" section.
- Add a stuck job to the CUPS queue. My way to do this is to add a network printer with URI "socket://0.0.0.0". As the driver I used the "Generic PCL Laser". Now, print a test page.
- Now we should be able to pinpoint the packages we want to upgrade to -proposed. Run command "sudo apt -t xenial-proposed install cups-daemon"
- Now we have a broken packaging system. The command "sudo apt upgrade" will fail.

Iiro Laiho (iiro) wrote :

The last step in #109 is important. When doing the upgrade of cups-daemon, it may look like it succeeded but with warnings. However, the packaging system does break down and will became unable to successfully do "apt upgrade".

Iiro Laiho (iiro) wrote :

Here are log entries that result from the "sudo apt -t xenial-proposed install cups-daemon"

Preparing to unpack .../libcupsppdc1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsppdc1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupsmime1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsmime1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupsimage2_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsimage2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupscgi1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupscgi1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-core-drivers_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-core-drivers (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-server-common_2.1.3-4ubuntu0.2_all.deb ...
Unpacking cups-server-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-common_2.1.3-4ubuntu0.2_all.deb ...
Unpacking cups-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-daemon_2.1.3-4ubuntu0.2_amd64.deb ...
Job for cups.service canceled.
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Job for cups.service canceled.
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: error processing archive /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.2_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
Preparing to unpack .../cups-bsd_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-bsd (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-client_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-client (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcups2_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcups2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Processing triggers for doc-base (0.10.7) ...
Processing 1 changed doc-base file...
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.2_amd64.deb
Log ended: 2017-08-08 19:32:01

And here is what happens when I try to run "apt upgrade" after that:

il@il-VirtualBox:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 cups : Depends: cups-daemon (>= 2.1.3-4ubuntu0.2)
 cups-core-drivers : Depends: cups-daemon (>= 2.1.3-4ubuntu0.2)
 cups-daemon : Depends: libcups2 (= 2.1.3-4) but 2.1.3-4ubuntu0.2 is installed
E: Unmet dependencies. Try using -f.

Eric Desrochers (slashd) wrote :

I tried the same exact reproducer (as described by iiro) using different scenarios such as :

- Server image inside LXC and KVM guest
- Server image inside KVM guest
- Desktop image inside a KVM guest

and every time it worked well for me without any issue.

- Eric

Iiro Laiho (iiro) wrote :

After talking with slashd, I did my own experiment in the same way I did with virtualbox, but this time I used virt-manager and KVM instead. Cannot reproduce. Maybe this has something to do with VirtualBox.

On Wed, Aug 09, 2017 at 04:28:43PM -0000, Iiro Laiho wrote:
> Cannot reproduce. Maybe this has something to do with VirtualBox.

Sounds like a race.

Iiro Laiho (iiro) wrote :

Here's the relevant journalctl log on VirtualBox. It complains something about colord. "Laitetta tai osoitetta ei ole" means "No such device or address".

elo 09 20:32:09 il-VirtualBox colord[1431]: (colord:1431): Cd-WARNING **: failed to get session [pid 3130]: Laitetta tai osoitetta ei ole
elo 09 20:32:18 il-VirtualBox systemd[1]: Stopped CUPS Scheduler.
elo 09 20:32:18 il-VirtualBox systemd[1]: Reloading.
elo 09 20:32:18 il-VirtualBox systemd[1]: Stopping Make remote CUPS printers available locally...
elo 09 20:32:18 il-VirtualBox systemd[1]: Started ACPI event daemon.
elo 09 20:32:18 il-VirtualBox systemd[1]: Stopped Make remote CUPS printers available locally.
elo 09 20:32:18 il-VirtualBox systemd[1]: Stopping CUPS Scheduler...
elo 09 20:32:18 il-VirtualBox systemd[1]: Started CUPS Scheduler.
elo 09 20:32:18 il-VirtualBox colord[1431]: (colord:1431): Cd-WARNING **: failed to get session [pid 6581]: Laitetta tai osoitetta ei ole
elo 09 20:32:18 il-VirtualBox systemd[1]: Stopped CUPS Scheduler.
elo 09 20:32:19 il-VirtualBox systemd[1]: Reloading.
elo 09 20:32:19 il-VirtualBox systemd[1]: Stopping CUPS Scheduler...
elo 09 20:32:19 il-VirtualBox systemd[1]: Started ACPI event daemon.
elo 09 20:32:19 il-VirtualBox systemd[1]: Started CUPS Scheduler.
elo 09 20:32:19 il-VirtualBox colord[1431]: (colord:1431): Cd-WARNING **: failed to get session [pid 6682]: Laitetta tai osoitetta ei ole
elo 09 20:32:20 il-VirtualBox systemd[1]: Reloading.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started ACPI event daemon.
elo 09 20:32:20 il-VirtualBox systemd[1]: Reloading.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started CUPS Scheduler.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started ACPI event daemon.
elo 09 20:32:20 il-VirtualBox systemd[1]: Reloading.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started ACPI event daemon.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started CUPS Scheduler.
elo 09 20:32:20 il-VirtualBox systemd[1]: Started CUPS Scheduler.

Eric Desrochers (slashd) wrote :

@iiro,

That is interesting ...

To recap using KVM you can't reproduce the situation (just like me) that you are experience using virtualbox ... so we are on the same page about not being able to reproduce using LXC nor KVM, but you can reproduce it if using virtualbox.

I'll give it a try this week and see if I can reproduce it using virtualbox.

Thanks a bunch iiro.

Please keep me posted if you find anything else relevant.

Regards,
Eric

Eric Desrochers (slashd) wrote :

@iiro,

I was able to reproduce the situation (explained in comment #111) ONLY using virtualbox.

To recap :

- Desktop image using KVM : Success # Same result for iiro and I
- Xenial image using LXC : Success
- Server image using KVM : Success
- Desktop image using Virtualbox : Fails # Same result for iiro and I

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/comments/111

Regards,
Eric

Eric Desrochers (slashd) wrote :
Download full text (3.8 KiB)

Using Desktop image on KVM :
--
Log started: 2017-08-08 14:07:24
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 175107 files and directories currently installed.)
Preparing to unpack .../libcupsppdc1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsppdc1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupsmime1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsmime1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupsimage2_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupsimage2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcupscgi1_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcupscgi1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-core-drivers_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-core-drivers (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-server-common_2.1.3-4ubuntu0.2_all.deb ...
Unpacking cups-server-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-common_2.1.3-4ubuntu0.2_all.deb ...
Unpacking cups-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-daemon_2.1.3-4ubuntu0.2_amd64.deb ...
Warning: Stopping cups.service, but it can still be activated by:
  cups.socket
Unpacking cups-daemon (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-bsd_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-bsd (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups-client_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups-client (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../libcups2_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking libcups2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Preparing to unpack .../cups_2.1.3-4ubuntu0.2_amd64.deb ...
Unpacking cups (2.1.3-4ubuntu0.2) over (2.1.3-4) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Processing triggers for doc-base (0.10.7) ...
Processing 1 changed doc-base file...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ufw (0.35-0ubuntu2) ...
Setting up libcups2:amd64 (2.1.3-4ubuntu0.2) ...
Setting up libcupsppdc1:amd64 (2.1.3-4ubuntu0.2) ...
Setting up libcupsmime1:amd64 (2.1.3-4ubuntu0.2) ...
Setting up libcupsimage2:amd64 (2.1.3-4ubuntu0.2) ...
Setting up libcupscgi1:amd64 (2.1.3-4ubuntu0.2) ...
Setting up cups-daemon (2.1.3-4ubuntu0.2) ...
Setting up cups-core-drivers (2.1.3-4ubuntu0.2) ...
Setting up cups-server-common (2.1.3-4ubuntu0.2) ...
Setting up cups-common (2.1.3-4ubuntu0.2) ...
Setting up cups-client (2.1.3-4ubuntu0.2) ...
Setting up cups-bsd (2.1.3-4ubuntu0.2) ......

Read more...

Eric Desrochers (slashd) wrote :

Using Desktop image on VirtualBox :

--
Log started: 2017-08-10 10:07:00
(Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 175107 files and directories currently installed.)^M
Preparing to unpack .../libcupsppdc1_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking libcupsppdc1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../libcupsmime1_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking libcupsmime1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../libcupsimage2_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking libcupsimage2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../libcupscgi1_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking libcupscgi1:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups-core-drivers_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking cups-core-drivers (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups-server-common_2.1.3-4ubuntu0.2_all.deb ...^M
Unpacking cups-server-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups-common_2.1.3-4ubuntu0.2_all.deb ...^M
Unpacking cups-common (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups-daemon_2.1.3-4ubuntu0.2_amd64.deb ...^M
Job for cups.service canceled.^M
invoke-rc.d: initscript cups, action "stop" failed.^M
dpkg: warning: subprocess old pre-removal script returned error exit status 1^M
dpkg: trying script from the new package instead ...^M
Job for cups.service canceled.^M
invoke-rc.d: initscript cups, action "stop" failed.^M
dpkg: error processing archive /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.2_amd64.deb (--unpack):^M
 subprocess new pre-removal script returned error exit status 1^M
Preparing to unpack .../cups-bsd_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking cups-bsd (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups-client_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking cups-client (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../libcups2_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking libcups2:amd64 (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Preparing to unpack .../cups_2.1.3-4ubuntu0.2_amd64.deb ...^M
Unpacking cups (2.1.3-4ubuntu0.2) over (2.1.3-4) ...^M
Processing triggers for libc-bin (2.23-0ubuntu9) ...^M
Processing triggers for doc-base (0.10.7) ...^M
Processing 1 changed doc-base file...^M
Processing triggers for man-db (2.7.5-1) ...^M
Errors were encountered while processing:^M
 /var/cache/apt/archives/cups-daemon_2.1.3-4ubuntu0.2_amd64.deb^M
Log ended: 2017-08-10 10:07:11
--

Eric Desrochers (slashd) wrote :

On a broken VirtualBox system, if I perform ;

systemctl stop cups.service

I got the following message : "Job for cups.service canceled."

Obviously, cups remain started with same PID, so no effect on the stop action requested.

Exactly as during the package upgrade.

On the other side, syslog shows :
Stopping CUPS Scheduler....
Started CUPS Scheduler.

followed by a colord message.

I purge colord as a debug exercise but problem remain the same.

Note that if I do :

systemctl restart cups.service

that works.

So seems like the culprit of the upgrade failure is around the fact that the VirtualBox guess can't properly stop cups.service.

but why ?

- Eric

Eric Desrochers (slashd) wrote :

If I manually stop or stop/start cups.socket & cups.path, then cups.service is stopping successfully, and I can now proceed with the cups upgrade on a broken system.

With that being said, this could be a good workaround for Xenial users blocked by this situation.

systemctl stop cups.socket
systemctl stop cups.path

and then :
systemctl stop cups.service

3 comments hidden view all 134 comments
Eric Desrochers (slashd) wrote :

Here's a debdiff[1] that I have tested and mitigate the situation with the reproducer using VirtualBox.

The proposal patch integrate a custom "debian/cups-daemon.prerm" maintainer script in case the pre-removal "old-version" from the installed package fails (as seen using the above reproducer) and then switch to the pre-removal script from the "new version" from the package to-be install in order to stop cups.socket and cups.path indivually before #DEBHELPER#.

[1] debdiff: lp1642966_xenial.debdiff

- Eric

Changed in cups (Ubuntu Xenial):
status: Triaged → In Progress
assignee: nobody → Eric Desrochers (slashd)
Eric Desrochers (slashd) on 2017-08-18
tags: added: regression-proposed
removed: verification-done-xenial
Eric Desrochers (slashd) wrote :

The patch has been uploaded in the xenial upload queue.

It is now waiting for the SRU verification team approval for the CUPS derived binary packages to start building in xenial-proposed and re-enter in the users test phase.

- Eric

An upload of cups to xenial-proposed has been rejected from the upload queue for the following reason: "Please re-upload including the changelog from the not-released-from-proposed 2.1.3-4ubuntu0.2 in the _changes file. This is needed for SRU tracking.".

Hello Mark, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.1.3-4ubuntu0.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in cups (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-xenial
Eric Desrochers (slashd) on 2017-08-23
description: updated
description: updated

About the c2esp regressio mentioned in the description (see also below):
It seems that c2esp never built/worked on arnhf. I see this also with several other printing-related packages (like cups-filters). So you can safely ignore it.

----------

Regression found in pending SRU page :

* Regression in autopkgtest for c2esp (armhf): test log

This autopkgtest seems to always fails :

http://autopkgtest.ubuntu.com/packages/c/c2esp/xenial/armhf

c2esp [xenial/armhf]

description: updated
Eric Desrochers (slashd) on 2017-08-23
description: updated
Eric Desrochers (slashd) on 2017-08-23
description: updated
description: updated

On Wed, Aug 23, 2017 at 02:54:51PM -0000, Till Kamppeter wrote:
> About the c2esp regressio mentioned in the description (see also below):
> It seems that c2esp never built/worked on arnhf. I see this also with
> several other printing-related packages (like cups-filters). So you can
> safely ignore it.

There are widespread failures to upgrade this package. We are trying to
publish an SRU, which by definition means we are going to be inducing users
to *upgrade the package*. Regardless of whether the c2esp package works on
armhf, it is built and the autopkgtest did pass in xenial until August of
last year. This is not going to be ignored without a very specific reason,
and if the c2esp autopkgtest happens to be exposing this same user-affecting
upgrade failure, then there is definitely no reason to ignore it.

Eric Desrochers (slashd) on 2017-08-23
description: updated
1 comments hidden view all 134 comments
Mateusz Pawlowski (matelukas) wrote :
Download full text (4.1 KiB)

I've tested upgrading cups-daemon package to version 2.1.3-4ubuntu0.3 on KVM, LXD and Virtualbox and I haven't found any issues so far.

Testbed specs:
1. KVM - Xenial 16.04 / qemu-system-x86 1:2.5+dfsg-5ubuntu10.14
2. LXD - Xenial 16.04 / lxd 2.0.10-0ubuntu1~16.04.1
3. Virtualbox - Xenial 16.04 / virtualbox 5.0.40-dfsg-0ubuntu1.16.04.1 / Extension_Pack-5.0.24

Upgrade results:
[KVM]
root@xenial:~# apt policy cups-daemon
cups-daemon:
Installed: 2.1.3-4
Candidate: 2.1.3-4ubuntu0.3
Version table:
2.1.3-4ubuntu0.3 500
500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
*** 2.1.3-4 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status

root@xenial:~# lpstat -t
scheduler is running
no system default destination
device for Dummy: http://hostname:631/ipp/
Dummy accepting requests since Thu 24 Aug 2017 03:27:51 PM UTC
printer Dummy now printing Dummy-1. enabled since Thu 24 Aug 2017 03:27:51 PM UTC
 Unable to locate printer "hostname".
Dummy-1 unknown 1024 Thu 24 Aug 2017 03:27:51 PM UTC
Dummy-2 unknown 1024 Thu 24 Aug 2017 03:27:56 PM UTC
Dummy-3 unknown 1024 Thu 24 Aug 2017 03:27:59 PM UTC

root@xenial:~# apt install -y cups-daemon 1>/dev/null 2>&1 && echo ok
ok

root@xenial:~# apt policy cups-daemon
cups-daemon:
Installed: 2.1.3-4ubuntu0.3
Candidate: 2.1.3-4ubuntu0.3
Version table:
*** 2.1.3-4ubuntu0.3 500
500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
100 /var/lib/dpkg/status
2.1.3-4 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

[Virtualbox]
root@cups-vb:~# apt policy cups-daemon
cups-daemon:
  Installed: 2.1.3-4
  Candidate: 2.1.3-4ubuntu0.3
  Version table:
     2.1.3-4ubuntu0.3 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
 *** 2.1.3-4 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

root@cups-vb:~# lpstat -t
scheduler is running
no system default destination
device for Dummy: http://hostname:631/ipp/
Dummy accepting requests since Thu Aug 24 17:41:19 2017
printer Dummy now printing Dummy-1. enabled since Thu Aug 24 17:41:19 2017
 Unable to locate printer "hostname".
Dummy-1 unknown 1024 Thu Aug 24 17:41:19 2017
Dummy-2 unknown 1024 Thu Aug 24 17:41:25 2017
Dummy-3 unknown 1024 Thu Aug 24 17:41:33 2017

root@cups-vb:~# apt install -y cups-daemon 1>/dev/null 2>&1 && echo ok
ok

root@cups-vb:~# apt policy cups-daemon
cups-daemon:
  Installed: 2.1.3-4ubuntu0.3
  Candidate: 2.1.3-4ubuntu0.3
  Version table:
 *** 2.1.3-4ubuntu0.3 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.1.3-4 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

[LXD]
root@juju-efafba-0:~# apt policy cups-daemon
cups-daemon:
  Installed: 2.1.3-4
  Candidate: 2.1.3-4ubuntu0.3
  Version table:
     2.1.3-4ubuntu0.3 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
 *...

Read more...

Eric Desrochers (slashd) on 2017-08-24
tags: added: verification-done verification-done-xenial
removed: patch regression-proposed verification-needed verification-needed-xenial
Sharad Rai (sharadrai) wrote :
Download full text (9.1 KiB)

I am able to install virtual box at Ubuntu now. I am not sure what was
update. This bug is related to any of my request ?

Thanks,
Sharad

On Thu, Aug 24, 2017 at 10:49 AM, Mateusz Pawlowski <
<email address hidden>> wrote:

> I've tested upgrading cups-daemon package to version 2.1.3-4ubuntu0.3 on
> KVM, LXD and Virtualbox and I haven't found any issues so far.
>
> Testbed specs:
> 1. KVM - Xenial 16.04 / qemu-system-x86 1:2.5+dfsg-5ubuntu10.14
> 2. LXD - Xenial 16.04 / lxd 2.0.10-0ubuntu1~16.04.1
> 3. Virtualbox - Xenial 16.04 / virtualbox 5.0.40-dfsg-0ubuntu1.16.04.1 /
> Extension_Pack-5.0.24
>
> Upgrade results:
> [KVM]
> root@xenial:~# apt policy cups-daemon
> cups-daemon:
> Installed: 2.1.3-4
> Candidate: 2.1.3-4ubuntu0.3
> Version table:
> 2.1.3-4ubuntu0.3 500
> 500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
> *** 2.1.3-4 500
> 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> root@xenial:~# lpstat -t
> scheduler is running
> no system default destination
> device for Dummy: http://hostname:631/ipp/
> Dummy accepting requests since Thu 24 Aug 2017 03:27:51 PM UTC
> printer Dummy now printing Dummy-1. enabled since Thu 24 Aug 2017
> 03:27:51 PM UTC
> Unable to locate printer "hostname".
> Dummy-1 unknown 1024 Thu 24 Aug 2017 03:27:51
> PM UTC
> Dummy-2 unknown 1024 Thu 24 Aug 2017 03:27:56
> PM UTC
> Dummy-3 unknown 1024 Thu 24 Aug 2017 03:27:59
> PM UTC
>
> root@xenial:~# apt install -y cups-daemon 1>/dev/null 2>&1 && echo ok
> ok
>
> root@xenial:~# apt policy cups-daemon
> cups-daemon:
> Installed: 2.1.3-4ubuntu0.3
> Candidate: 2.1.3-4ubuntu0.3
> Version table:
> *** 2.1.3-4ubuntu0.3 500
> 500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
> 100 /var/lib/dpkg/status
> 2.1.3-4 500
> 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
>
> [Virtualbox]
> root@cups-vb:~# apt policy cups-daemon
> cups-daemon:
> Installed: 2.1.3-4
> Candidate: 2.1.3-4ubuntu0.3
> Version table:
> 2.1.3-4ubuntu0.3 500
> 500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64
> Packages
> *** 2.1.3-4 500
> 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> root@cups-vb:~# lpstat -t
> scheduler is running
> no system default destination
> device for Dummy: http://hostname:631/ipp/
> Dummy accepting requests since Thu Aug 24 17:41:19 2017
> printer Dummy now printing Dummy-1. enabled since Thu Aug 24 17:41:19 2017
> Unable to locate printer "hostname".
> Dummy-1 unknown 1024 Thu Aug 24 17:41:19 2017
> Dummy-2 unknown 1024 Thu Aug 24 17:41:25 2017
> Dummy-3 unknown 1024 Thu Aug 24 17:41:33 2017
>
> root@cups-vb:~# apt install -y cups-daemon 1>/dev/null 2>&1 && echo ok
> ok
>
> root@cups-vb:~# apt policy cups-daemon
> cups-daemon:
> Installed: 2.1.3-4ubuntu0.3
> Candidate: 2.1.3-4ubuntu0.3
> Version table:
> *** 2.1.3-4ubuntu0.3 500
> 500 http://archive.ubuntu.com/ubu...

Read more...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups - 2.1.3-4ubuntu0.3

---------------
cups (2.1.3-4ubuntu0.3) xenial; urgency=high

  * Adding maintainer script debian/cups-daemon.prerm to deal with situations
    where "old-version" (installed package) prerm script fails. (LP: #1642966).

cups (2.1.3-4ubuntu0.2) xenial; urgency=medium

  * Make cups.path unit be part of the cups.service, since cups.path
    should stop if and when cups.service is stopped. LP: #1642966

cups (2.1.3-4ubuntu0.1) xenial-proposed; urgency=medium

  * Removed auto-shutdown-on-idle-also-with-webinterface-on.patch
    as it causes CUPS to auto-shutdown when web interface support is
    active (LP: #1598300).

 -- Eric Desrochers <email address hidden> Fri, 18 Aug 2017 12:08:28 -0400

Changed in cups (Ubuntu Xenial):
status: Fix Committed → Fix Released
Displaying first 40 and last 40 comments. View all 134 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.