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

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.

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.

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

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.

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.

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

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

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

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)

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.

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

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.

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

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

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.

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.

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

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

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.

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

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.

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

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

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

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

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

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.

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?

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.

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.

> 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

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

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.

Tanks

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.

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.

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

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?

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

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.

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?

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.

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.

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.

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.

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

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

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

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

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

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
>

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

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

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!

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!

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.

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.

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.

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.

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.

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

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.

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

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

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!

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.

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?

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

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.

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.

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

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?

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.

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?

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

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

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!

Wie kann ich als Anfänger den Schaden beheben?

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.

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

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

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

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.

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

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.

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

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.

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.

@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

@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

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

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

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

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

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

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!

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]

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.

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

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

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

I have a question

if I were to re-install ubuntu would it delete my existing e-mails?

ANDREW . . .
On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
>

I don't know.

On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden> wrote:

> I have a question
>
> if I were to re-install ubuntu would it delete my existing e-mails?
>
>
> ANDREW . . .
> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1676430).
> 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 Released
> Status in cups source package in Zesty:
> Fix Released
>
> 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 r...

can you direct me to someone who would know?

ANDREW . . .
On 11/19/2017 03:12 PM, Tinku Girdhar wrote:
> I don't know.
>
> On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden>
> wrote:
>
>> I have a question
>>
>> if I were to re-install ubuntu would it delete my existing e-mails?
>>
>>
>> ANDREW . . .
>> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
>>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (1676430).
>> 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 Released
>> Status in cups source package in Zesty:
>> Fix Released
>>
>> 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
>>...

not if you backup and restore your home directory OR have it on a separate
partition.

On Sun, Nov 19, 2017 at 3:30 PM andrew buffa <email address hidden>
wrote:

> can you direct me to someone who would know?
>
> ANDREW . . .
> On 11/19/2017 03:12 PM, Tinku Girdhar wrote:
> > I don't know.
> >
> > On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden>
> > wrote:
> >
> >> I have a question
> >>
> >> if I were to re-install ubuntu would it delete my existing e-mails?
> >>
> >>
> >> ANDREW . . .
> >> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
> >>>
> >> --
> >> You received this bug notification because you are subscribed to a
> >> duplicate bug report (1676430).
> >> 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 Released
> >> Status in cups source package in Zesty:
> >> Fix Released
> >>
> >> 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
> >> ...

thank you very much

Happy Thanksgiving

ANDREW . . .
On 11/19/2017 03:57 PM, caj411 wrote:
> not if you backup and restore your home directory OR have it on a separate
> partition.
>
> On Sun, Nov 19, 2017 at 3:30 PM andrew buffa <email address hidden>
> wrote:
>
>> can you direct me to someone who would know?
>>
>> ANDREW . . .
>> On 11/19/2017 03:12 PM, Tinku Girdhar wrote:
>>> I don't know.
>>>
>>> On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden>
>>> wrote:
>>>
>>>> I have a question
>>>>
>>>> if I were to re-install ubuntu would it delete my existing e-mails?
>>>>
>>>>
>>>> ANDREW . . .
>>>> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
>>>>>
>>>> --
>>>> You received this bug notification because you are subscribed to a
>>>> duplicate bug report (1676430).
>>>> 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 Released
>>>> Status in cups source package in Zesty:
>>>> Fix Released
>>>>
>>>> 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
>>>> CupsErro...

Sure
<email address hidden>
You can refer to him

On 20-Nov-2017 5:11 AM, "andrew buffa" <email address hidden> wrote:

> thank you very much
>
> Happy Thanksgiving
>
> ANDREW . . .
> On 11/19/2017 03:57 PM, caj411 wrote:
> > not if you backup and restore your home directory OR have it on a
> separate
> > partition.
> >
> > On Sun, Nov 19, 2017 at 3:30 PM andrew buffa <<email address hidden>
> >
> > wrote:
> >
> >> can you direct me to someone who would know?
> >>
> >> ANDREW . . .
> >> On 11/19/2017 03:12 PM, Tinku Girdhar wrote:
> >>> I don't know.
> >>>
> >>> On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden>
> >>> wrote:
> >>>
> >>>> I have a question
> >>>>
> >>>> if I were to re-install ubuntu would it delete my existing e-mails?
> >>>>
> >>>>
> >>>> ANDREW . . .
> >>>> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
> >>>>>
> >>>> --
> >>>> You received this bug notification because you are subscribed to a
> >>>> duplicate bug report (1676430).
> >>>> 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 Released
> >>>> Status in cups source package in Zesty:
> >>>> Fix Released
> >>>>
> >>>> 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
> >>>> Di...

Olá, desde já muito obrigado pela atenção pois eu fiz uma atualização do
Ubuntu para a versão 17.04 desde já muito obrigado pela ajuda.

Em 20 de nov de 2017 6:21 AM, "Tinku Girdhar" <email address hidden>
escreveu:

> Sure
> <email address hidden>
> You can refer to him
>
> On 20-Nov-2017 5:11 AM, "andrew buffa" <email address hidden>
> wrote:
>
> > thank you very much
> >
> > Happy Thanksgiving
> >
> > ANDREW . . .
> > On 11/19/2017 03:57 PM, caj411 wrote:
> > > not if you backup and restore your home directory OR have it on a
> > separate
> > > partition.
> > >
> > > On Sun, Nov 19, 2017 at 3:30 PM andrew buffa <
> <email address hidden>
> > >
> > > wrote:
> > >
> > >> can you direct me to someone who would know?
> > >>
> > >> ANDREW . . .
> > >> On 11/19/2017 03:12 PM, Tinku Girdhar wrote:
> > >>> I don't know.
> > >>>
> > >>> On 20-Nov-2017 12:01 AM, "andrew buffa" <email address hidden>
> > >>> wrote:
> > >>>
> > >>>> I have a question
> > >>>>
> > >>>> if I were to re-install ubuntu would it delete my existing e-mails?
> > >>>>
> > >>>>
> > >>>> ANDREW . . .
> > >>>> On 08/31/2017 08:22 AM, Launchpad Bug Tracker 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
> > >>>>>
> > >>>> --
> > >>>> You received this bug notification because you are subscribed to a
> > >>>> duplicate bug report (1676430).
> > >>>> 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 Released
> > >>>> Status in cups source package in Zesty:
> > >>>> Fix Released
> > >>>>
> > >>>> Bug description:
> > >>>> This concerns only Xenial (16.04)!
> > >>>>
> > >>>> [Impact]
> > >>>> * fail to upgrade
> > >>>>
> > >>>> [testcase]
> > >>>> Root cause is believed to be re...