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 779 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
High
Unassigned
Xenial
High
Unassigned
Yakkety
High
Unassigned
Zesty
High
Unassigned

Bug Description

This is in xenial-proposed, please block release to -updates accordingly :)

[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.

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.

Reported CUPS upstream bug:

https://github.com/apple/cups/issues/4930

/lib/systemd/system/cups.path and keepalive file /var/cache/cups/org.cups.cupsd do not make sense with systemd

Martin Pitt (pitti) wrote :

> Requires=cups.service in /lib/systemd/system/cups-browsed.service the shutdown of CUPS should shutdown cups-browsed first.

No -- Requires/Wants start/stop other units, but they *do not imply ordering*. If you need to order services against each other you must additionally specify Before/After=.

Martin Pitt (pitti) wrote :

Till's log shows that cups.path triggers after cups got stopped:

Dec 02 10:59:15 till-x1carbon systemd[1]: cups.path: Got notified about unit deactivation.
Dec 02 10:59:15 till-x1carbon systemd[1]: cups.path: Changed running -> waiting
Dec 02 10:59:15 till-x1carbon systemd[1]: cups.socket: Changed running -> listening
[...]
Dec 02 10:59:19 till-x1carbon systemd[1]: cups.path: Got triggered.
Dec 02 10:59:19 till-x1carbon systemd[1]: cups.service: Trying to enqueue job cups.service/start/replace

and soon afterwards something stops it again:

Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Trying to enqueue job cups.service/stop/replace
Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Installed new job cups.service/stop as 6213
[...]
Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Changed running -> stop-sigterm
Dec 02 10:59:29 till-x1carbon systemd[1]: Stopping CUPS Scheduler...

and then starts again:

Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Got triggered.
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Trying to enqueue job cups.service/start/replace

but cups shuts down again:

Dec 02 10:59:30 till-x1carbon systemd[1]: Child 9764 (cupsd) died (code=exited, status=0/SUCCESS
)
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Child 9764 belongs to cups.service
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Main process exited, code=exited, status=0/SUCCESS
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Changed stop-sigterm -> dead
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Got notified about unit deactivation.
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Changed running -> waiting

and so on, and I suppose eventually it runs into the restart limit.

Unfortunately the description of all cups.* unit is identical ("CUPS Scheduler" so on a non-debug log it is a bit hard to see which of the three it is when it says "Stopped". But nowhere in Till's log I see that cups.path itself gets stopped (and neither cups.service) -- this is clearly missing for a reliable stopping.

Ivan (ivandelirio) wrote :

Tanks

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

Discussed the reason why CUOS has the keepalive file in the upstream bug report

https://github.com/apple/cups/issues/4930

In CUPS everything is OK and as intended. The bug seems to be in systemd.

And there is also another bug in systemd: The *.path file as it comes with CUPS should always start CUPS (if it is not already running) if there is the keepalive file, not only if the keepalive file is newly created.

Changed in init-system-helpers (Ubuntu):
importance: Undecided → High
Changed in systemd (Ubuntu):
importance: Undecided → High

pitti, first, in the shutdown process of CUPS cups.path has to be deactivated first, so that the presence of the keepalive file of CUPS does not cause an immediate restart. After that, the other unit files of CUPS need to get deactivated to complete the shutdown.

Concerning cups-browsed (which can, while running, trigger CUPS via socket), The unit file

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

contains

After=cups.service avahi-daemon.service

in its [Unit] section. Is this enough to make cups-browsed being shut down before the shutdown of CUPS is done? Or do I need to add another line.

Martin Pitt (pitti) on 2016-12-05
Changed in cups (Ubuntu):
status: Invalid → Confirmed
Martin Pitt (pitti) wrote :

> In CUPS everything is OK and as intended.

No -- as above, the maintainer scripts need to stop cups.{socket,path} first before stopping cups.service. Also, as it seems you can entirely drop that .path unit as it's fairly useless -- we don't start cups on demand, but it always starts on boot (in a default install). It would of course be nice to fix that (as I suggested in the upstream bug).

> And there is also another bug in systemd: The *.path file as it comes with CUPS should always start CUPS (if it is not already running) if there is the keepalive file, not only if the keepalive file is newly created.

It does -- that's precisely what happens here: The path unit restarts cups after the maintainer scripts stop it, and that's the core of this bug. So if anything, you want it to be less aggressive, not more :-)

> cups-browsed.service contains "After=cups.service avahi-daemon.service" in its [Unit] section. Is this enough to make cups-browsed being shut down before the shutdown of CUPS is done?

Yes, it is, the Before/After get inversed on stopping units.

tags: removed: need-duplicate-check

pitti, as far as I know the debhelpers add the needed steps to the maintainer scripts of the cups-daemon package. So it seems that the debhelpers do not add the required commands.

I have observed something which could be the cause of the problem. On older builds of CUPS I get the following prerm script for cups-daemon (after build debian/cups-daemon/DEBIAN/prerm in source tree, after install /var/lib/dpkg/info/cups-daemon.prerm):

----------
#!/bin/sh
set -e
# Automatically added by dh_installdeb
dpkg-maintscript-helper mv_conffile /etc/pam.d/cups-daemon /etc/pam.d/cups 1.7.3-2~ -- "$@"
# End automatically added section
# Automatically added by dh_installdeb
dpkg-maintscript-helper rm_conffile /etc/default/cups 1.7.1-6~ -- "$@"
# End automatically added section
# Automatically added by dh_installdeb
dpkg-maintscript-helper rm_conffile /etc/cups/cupsd.conf.default 1.7.1-3~ -- "$@"
# End automatically added section
# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
 deb-systemd-invoke stop cups.path >/dev/null
fi
# End automatically added section
# Automatically added by dh_installinit
if [ -x "/etc/init.d/cups" ] || [ -e "/etc/init/cups.conf" ]; then
 invoke-rc.d cups stop || exit $?
fi
# End automatically added section
----------

The debhelpers added a call to explicitly shut down cups.path.

The same file in a Yakkety system or after building CUPS (2.2.1-2) in Zesty is:

----------
#!/bin/sh
set -e
# Automatically added by dh_installdeb
dpkg-maintscript-helper mv_conffile /etc/pam.d/cups-daemon /etc/pam.d/cups 1.7.3-2~ -- "$@"
# End automatically added section
# Automatically added by dh_installdeb
dpkg-maintscript-helper rm_conffile /etc/default/cups 1.7.1-6~ -- "$@"
# End automatically added section
# Automatically added by dh_installdeb
dpkg-maintscript-helper rm_conffile /etc/cups/cupsd.conf.default 1.7.1-3~ -- "$@"
# End automatically added section
# Automatically added by dh_installinit
if [ -x "/etc/init.d/cups" ]; then
        invoke-rc.d cups stop || exit $?
fi
# End automatically added section
----------

Here the call to stop cups.path is missing.

In both cases also the last part seems to be strange, as it seems to support only System V Init and Upstart, not systemd. The "if" does not check for the presence of systemd support (unit file).

xnox, can you have a look into this?

Steven Jones (svjones44us) wrote :

Till- Still having a problem with this. The auto updates will not launch and I have several program updates that are on hold. Additionally, I have tried to install several pieces of software from the library and the authentication link does not launch.

Steve Jones

Sacramento, CA USA

________________________________
From: <email address hidden> <email address hidden> on behalf of Till Kamppeter <email address hidden>
Sent: Friday, December 9, 2016 9:08:31 AM
To: <email address hidden>
Subject: [Bug 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

xnox, can you have a look into this?

--
You received this bug notification because you are subscribed to a
duplicate bug report (1643257).
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
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd 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

Changed in systemd (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-16.12

Anyone suffering the problem, please take one of the reproducers mentioned in this bug report (for example comment #18) and retry to see whether you still are able to reproduce it.

Then edit the file /lib/systemd/system/cups.path adding a line "PartOf=cups.service" to the [Unit] section, so that the file looks like this:

----------
[Unit]
Description=CUPS Scheduler
PartOf=cups.service

[Path]
PathExists=/var/cache/cups/org.cups.cupsd

[Install]
WantedBy=multi-user.target
----------

Save the file and run the command:

systemctl daemon-reload

Now run the reproducer again and check whether the problem has gone away.

Please tell us your results.

Anthony Ledford (tony-csu0kx) wrote :

Editing /lib/systemd/system/cups.path as instructed in post #52 above has resolved the issue on my 16.04 LTS install.

Reported the suggested solution of comment #52 to CUPS upstream as

https://github.com/apple/cups/issues/4935

The change will get applied in the next release of CUPS (2.2.2, in January).

xnox, it seems that the suggested fix of comment #52 is the solution for this bug, and I could at any time add a patch to the CUPS package and issue it as an SRU. Only problem is, if I do only this, will the SRU smoothly install? Or are additional measures required?

Martin Pitt (pitti) wrote :

Till Kamppeter [2016-12-19 16:48 -0000]:
> Then edit the file /lib/systemd/system/cups.path adding a line
> "PartOf=cups.service" to the [Unit] section, so that the file looks like
> this:
>
> ----------
> [Unit]
> Description=CUPS Scheduler
> PartOf=cups.service

I suppose that cups.path is only for booting, i. e. you want to start
cups.service on boot, not again on demand on a running system. Does it ever
happen that cups.service terminates by itself due to inactivity? If not, this
provides a good enough workaround for not stopping cups.path properly in the
maintainer scripts. If yes, this appproach doesn't work.

Note that you probably want to do the same for cups.socket, with the same
reasoning as above.

Dimitri John Ledkov (xnox) wrote :

On 21 December 2016 at 08:13, Martin Pitt <email address hidden> wrote:
>
> Till Kamppeter [2016-12-19 16:48 -0000]:
> > Then edit the file /lib/systemd/system/cups.path adding a line
> > "PartOf=cups.service" to the [Unit] section, so that the file looks like
> > this:
> >
> > ----------
> > [Unit]
> > Description=CUPS Scheduler
> > PartOf=cups.service
>
> I suppose that cups.path is only for booting, i. e. you want to start
> cups.service on boot, not again on demand on a running system. Does it ever
> happen that cups.service terminates by itself due to inactivity? If not, this
> provides a good enough workaround for not stopping cups.path properly in the
> maintainer scripts. If yes, this appproach doesn't work.
>
> Note that you probably want to do the same for cups.socket, with the same
> reasoning as above.
>

I'm not sure, but I thought we want to keep cups.socket around, after
cups.service self-shutdowns during normal system operation, because we
want to keep cups.service socket activatable.

IMHO cups.path should be removed, and instead a generator used to add
cups.service to multi-user.target.wants on boot if the state file
indicates we want cups.service to be always running.

--
Regards,

Dimitri.

Dimitri John Ledkov (xnox) wrote :

On 20 December 2016 at 21:39, Till Kamppeter <email address hidden> wrote:
> xnox, it seems that the suggested fix of comment #52 is the solution for
> this bug, and I could at any time add a patch to the CUPS package and
> issue it as an SRU. Only problem is, if I do only this, will the SRU
> smoothly install? Or are additional measures required?
>

Looking at:
https://wiki.debian.org/MaintainerScripts

The new package, may need to have a preinst stanza which version
checks which package version upgrade is happening from and still
execute systemctl stop cups.path unit.
Upgrades after that one should be fine without a preinst.
And preinst should then be dropped after next LTS.

Obviously a new package needs to be prepared and we should test it a bit.

Shall we start a https://bileto.ubuntu.com/ devirt PPA for this update
into zesty and eventual SRUs?

--
Regards,

Dimitri.

xnox, I think that your suggestion of a generator in comment #57 makes things too complicated. The "PartOf=cups.service" solution works just fine.

But could you prepare a debdiff and/or PPA package implementing your suggestion of comment #58? Thanks.

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)

Upstream bug

https://github.com/apple/cups/issues/4935

is fixed now, the fix will be in upstream CUPS from version 2.2.2 on.

Dimitri John Ledkov (xnox) wrote :

SRU is uploaded into bileto silo at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2323/+packages
Bileto details at https://bileto.ubuntu.com/#/ticket/2323

It is an ephemeral PPA which will be removed after this SRU is published.

One can test this proposed update by enabling it with:

sudo add-apt-repository ppa:ci-train-ppa-service/2323
sudo apt-get update
sudo apt full-upgrade

David Wonderly (osxdos) wrote :
Download full text (5.5 KiB)

Thx

On Dec 22, 2016 12:01 PM, "Dimitri John Ledkov" <email address hidden>
wrote:

> ** Description changed:
>
> This is in xenial-proposed, please block release to -updates accordingly
> :)
> +
> + [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
> + 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.
>
> --
> 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
> Status in init-system-helpers package in Ubuntu:
> Confirmed
> Status in systemd package in Ubuntu:
> Confirmed
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> [Impact]
> * fail to upgrade
>
> [testcase]
> R...

Read more...

Changed in cups (Ubuntu Zesty):
milestone: ubuntu-16.12 → ubuntu-17.01

xnox, if you make an SRU for this bug, can you merge it with the SRU for bug 1598300. Thanks.

Changed in cups (Ubuntu Zesty):
milestone: ubuntu-17.01 → ubuntu-17.02
rusbunker (rusbunker) wrote :

Дмитрий добрый день! Я правильно понимаю что если выполню инструкции
прописанные в этом сообщении, я получу желаемое? А именно устновлю принтер.

31.01.2017 13:33, Dimitri John Ledkov пишет:
> ** Changed in: cups (Ubuntu Zesty)
> Milestone: ubuntu-17.01 => ubuntu-17.02
>

rusbunker (rusbunker) wrote :

yes. I purge driver of printer and reinstall it again. That all.
Everything ok.

03.02.2017 00:37, andrew buffa пишет:
> how do I fix?
>
> I now have no internet connection
>
> am using a backup pc
>
> Andrew
> On 1/31/2017 11:56 PM, rusbunker wrote:
>> Дмитрий добрый день! Я правильно понимаю что если выполню инструкции
>> прописанные в этом сообщении, я получу желаемое? А именно устновлю принтер.
>>
>>
>> 31.01.2017 13:33, Dimitri John Ledkov пишет:
>>> ** Changed in: cups (Ubuntu Zesty)
>>> Milestone: ubuntu-17.01 => ubuntu-17.02
>>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Iiro Laiho (iiro) wrote :

The change is already done since the package was updated to the lastest upstream version.

Changed in cups (Ubuntu Zesty):
assignee: Dimitri John Ledkov (xnox) → nobody
status: Triaged → Fix Released
Iiro Laiho (iiro) wrote :

Added patch tag because there is a patched PPA linked in comment #61.

tags: added: patch

Hello Mark, or anyone else affected,

Accepted cups into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.2.0-2ubuntu0.1 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 to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. 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 Yakkety):
status: Triaged → Fix Committed
tags: added: verification-needed
Brian Murray (brian-murray) wrote :

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.2 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 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 to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. 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: Triaged → Fix Committed

This bug report got 418 (!) me-too votes and has tons of duplicates and no one wants to verify the proposed fix? Please, come up, install the proposed package and see whether it installs smoothly without hick-up and give us your feedback here. You will help a lot of people if your feedback makes the fix getting an official update.

Thank you very much.

And we are on 419 me-too votes now! So who ever has voted now, please try the proposed fix! Thanks.

ais523 (ais523) wrote :

Just to clarify why this bug has so many me-too votes: the bug happened once to me, during an update, and never happened again (i.e. it fixed itself, and I can print just fine, etc.). I subscribed to this thread because I was curious as to what was going on, and I did see the problem myself once but the bug doesn't have any ongoing effect on me and I can't reproduce it.

I suspect that the majority of the people who have confirmed the bug are in the same boat, whereas some people here have the issue recurring for some reason. (It's unclear why; either there's something relevantly different about their configuration, or this is actually two different bugs with the same symptoms.) So although there are a lot of people here, I suspect rather fewer people are in a position to test the fix; I can't reproduce the bug, and thus there's no point in me testing the fix, as a working fix would look the same as a fix that had no effect at all.

Would it be reasonable for people in my position to retract our confirmations of the bug, if we can no longer reproduce? Or is it best to leave the confirmation there, because I definitely did see the bug happen, once?

Note that this bug is only a problem of the package installation process. So it is fixed (or not reproducible) if you install the proposed package and the installation does not error. There is no difference between before and after on the system's behavior.

Iiro Laiho (iiro) wrote :

I ran this test. The machine was a 64-bit Ubuntu 16.04.2 on a VirtualBox VM. Before running the command I enabled -proposed and ensured that CUPS will not shut down by having a stuck job in the queue. The upgrade completed correctly.

Console output of the "apt update && apt install cups-daemon" command attached.

Iiro Laiho (iiro) wrote :

Also, the test case in the bug report seems to return 0 unless there is a job in queue. That job does not however affect the update process, so I'll put verification-done to this.

tags: added: verification-done
removed: verification-needed
Robie Basak (racb) wrote :

Looks like you verified Xenial but not Yakkety? Not a problem and we appreciate your testing; just adjusting the tags so we don't accidentally release an untested Yakkety.

tags: added: verification-done-xenial
removed: verification-done
Launchpad Janitor (janitor) wrote :

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

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

 -- Dimitri John Ledkov <email address hidden> Thu, 22 Dec 2016 17:08:36 +0000

Changed in cups (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for cups has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Download full text (3.4 KiB)

desculpe mas eu removi o sistema e coloquei outro sistema

2017-03-27 4:22 GMT-03:00 Robie Basak <email address hidden>:

> Looks like you verified Xenial but not Yakkety? Not a problem and we
> appreciate your testing; just adjusting the tags so we don't
> accidentally release an untested Yakkety.
>
> ** Tags removed: verification-done
> ** Tags added: verification-done-xenial
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Fix Released
> Status in cups source package in Xenial:
> Fix Released
> Status in cups source package in Yakkety:
> Fix Committed
> Status in cups source package in Zesty:
> Fix Released
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> [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.:
> pnXPS159...

Read more...

Frode Nordahl (fnordahl) wrote :

The package that was just SRU'ed caused this very error. Apport-info in LP: #1676380

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

Before getting to here, I did sudo apt-get -f install , but there are the log files:

error_log 0 byte

error_log.1 291 bytes
E [23/Mar/2017:11:22:34 -0300] [cups-deviced] PID 4786 (gutenprint52+usb) stopped with status 1!
E [24/Mar/2017:10:13:07 -0300] [cups-deviced] PID 3065 (gutenprint52+usb) stopped with status 1!
E [24/Mar/2017:10:15:04 -0300] [cups-deviced] PID 1825 (gutenprint52+usb) stopped with status 1!

Robie Basak (racb) wrote :

This appears not yet fixed in Xenial in 2.1.3-4ubuntu0.2. After releasing 2.1.3-4ubuntu0.2 we got further reports that I'm duping to bug 1676380.

Changed in cups (Ubuntu Xenial):
status: Fix Released → Triaged
description: updated

xnox, your fixed package actually contains the fix we agreed on to apply and it even seems to work in the newer Ubuntu versions Yakkety and Zesty, but seems not to work in Xenial. Do you have any idea what is happening here? Perhaps a bug in systemd?

caj411 (cajones) wrote :
Download full text (3.4 KiB)

I forced the update with sudo apt-get -f upgrade and it worked, so I guess
its a mute point. thanks

On Mon, Mar 27, 2017 at 2:41 PM Till Kamppeter <email address hidden>
wrote:

> xnox, your fixed package actually contains the fix we agreed on to apply
> and it even seems to work in the newer Ubuntu versions Yakkety and
> Zesty, but seems not to work in Xenial. Do you have any idea what is
> happening here? Perhaps a bug in systemd?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Fix Released
> Status in cups source package in Xenial:
> Triaged
> Status in cups source package in Yakkety:
> Fix Released
> Status in cups source package in Zesty:
> Fix Released
>
> Bug description:
> This is in xenial-proposed, please block release to -updates
> accordingly :)
>
> [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...

Read more...

xnox, a possible cause can be that when the old package is removed before the update, the shutdown is perhaps made with the old systemd service files (which do not contain the fix). So probably additional methods, like explicitly deactivating cups.path, or at least restarting systemd need to get performed. Strange is that this is not needed in Yakkety and Zesty.

Rolland4 (suhaneshmadav) wrote :

It's all started when I tried to install Dropbox 64bit deb package from their website.Two systems got effected in same manner.

A problem of this bug seems to be that it occurs only once for each user. So a user who observed in in the first place will not observe it again when it comes to verification of the SRU. So the SRU gets verified even without the bug actually fixed. The complaints after the SRU having put into -updates are from users who only updated their systems afterwards and not before the initial bug report.

Julian Paredes (jparedes) wrote :

Changed xenial status by error, should be 'Triaged'. Can't change it back, sorry :(

Changed in cups (Ubuntu Xenial):
status: Triaged → Confirmed
Changed in cups (Ubuntu Xenial):
status: Confirmed → Triaged
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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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