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.

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