cupsys-driver-gimpprint update error

Bug #14187 reported by Mike Basinger
6
Affects Status Importance Assigned to Milestone
gimp-print (Ubuntu)
Fix Released
High
Adam Conrad

Bug Description

I'm getting the following error when trying to upgrade cupsys-driver-gimpprint
usinf apt-get dist-upgrade

dbasinge@pheonix:~$ sudo apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up cupsys-driver-gimpprint (4.2.7-4ubuntu2) ...
No Gimp-Print PPD files to update.
 * Restarting Common Unix Printing System: cupsd
cupsd: Child exited with status 98!
dpkg: error processing cupsys-driver-gimpprint (--configure):
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 cupsys-driver-gimpprint
E: Sub-process /usr/bin/dpkg returned an error code (1)

Revision history for this message
Adam Conrad (adconrad) wrote :

It would be much easier to track this down if I could see the contents
of /var/log/cups/error_log immediately after the apt-get/dpkg run.
Probably the last 10 lines or so should be what we're after.

Revision history for this message
Tomas Vilda (tomas-vilda) wrote :

(In reply to comment #1)
> It would be much easier to track this down if I could see the contents
> of /var/log/cups/error_log immediately after the apt-get/dpkg run.
> Probably the last 10 lines or so should be what we're after.

I have the same error after last update, so here are the lines:

I [21/Mar/2005:16:38:41 +0200] Listening to 7f000001:631
I [21/Mar/2005:16:38:41 +0200] Loaded configuration file "/etc/cups/cupsd.conf"
I [21/Mar/2005:16:38:41 +0200] Configured for up to 100 clients.
I [21/Mar/2005:16:38:41 +0200] Allowing up to 100 client connections per host.
I [21/Mar/2005:16:38:41 +0200] Full reload is required.
I [21/Mar/2005:16:38:41 +0200] LoadPPDs: Read "/etc/cups/ppds.dat", 2348
PPDs...I [21/Mar/2005:16:38:42 +0200] LoadPPDs: No new or changed PPDs...
I [21/Mar/2005:16:38:42 +0200] Full reload complete.
I [21/Mar/2005:16:42:34 +0200] Scheduler shutting down normally.
I [21/Mar/2005:16:42:35 +0200] Listening to 7f000001:631
I [21/Mar/2005:16:42:35 +0200] Loaded configuration file "/etc/cups/cupsd.conf"
I [21/Mar/2005:16:42:35 +0200] Configured for up to 100 clients.
I [21/Mar/2005:16:42:35 +0200] Allowing up to 100 client connections per host.
I [21/Mar/2005:16:42:35 +0200] Full reload is required.
I [21/Mar/2005:16:42:35 +0200] LoadPPDs: Read "/etc/cups/ppds.dat", 2348
PPDs...I [21/Mar/2005:16:42:35 +0200] LoadPPDs: No new or changed PPDs...
I [21/Mar/2005:16:42:35 +0200] Full reload complete.
E [21/Mar/2005:16:42:35 +0200] StartListening: Unable to bind socket for address
7f000001:631 - Cannot assign requested address.

Revision history for this message
Daniel Robitaille (robitaille) wrote :

A little wild guess here: maybe a "sleep 5" after the "kill -9" as it was
originally proposed in latest patch for cupsys.postinst (Comment #6 of Bug 11037)
would do the trick; or maybe an additional sleep somewhere else in that script?
 Maybe cupsys doesn't have the time to properly stop before its restart in some
configurations? (I know that I haven't experienced this problem on my computer
during the last cupsys upgrade)

Revision history for this message
Matt Zimmerman (mdz) wrote :

No amount of additional sleeping will provide the necessary level of robustness;
even if it is not possible to stop the old instance of the daemon, this should
not abort the upgrade

Revision history for this message
Hal Finkel (hal-finkel) wrote :

I just installed Ubuntu today (Ubuntu 5.04 _Hoary Hedgehog_ - Preview i386), so
this may not be the cause of the problem for previously installed systems,
however, on my system the problem was caused by the lack of an ipv4 loopback
(the lo interface had an ipv6 address but not the ipv4 address of 127.0.0.1).
Thus, running "ifconfig lo inet 127.0.0.1" as root solved the problem.

(In reply to comment #0)
> I'm getting the following error when trying to upgrade cupsys-driver-gimpprint
> usinf apt-get dist-upgrade
>
> dbasinge@pheonix:~$ sudo apt-get dist-upgrade
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Calculating Upgrade... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> Need to get 0B of archives.
> After unpacking 0B of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Setting up cupsys-driver-gimpprint (4.2.7-4ubuntu2) ...
> No Gimp-Print PPD files to update.
> * Restarting Common Unix Printing System: cupsd
> cupsd: Child exited with status 98!
> dpkg: error processing cupsys-driver-gimpprint (--configure):
> subprocess post-installation script returned error exit status 2
> Errors were encountered while processing:
> cupsys-driver-gimpprint
> E: Sub-process /usr/bin/dpkg returned an error code (1)

(In reply to comment #3)
> A little wild guess here: maybe a "sleep 5" after the "kill -9" as it was
> originally proposed in latest patch for cupsys.postinst (Comment #6 of Bug 11037)
> would do the trick; or maybe an additional sleep somewhere else in that script?
> Maybe cupsys doesn't have the time to properly stop before its restart in some
> configurations? (I know that I haven't experienced this problem on my computer
> during the last cupsys upgrade)
>
>

Revision history for this message
Adam Conrad (adconrad) wrote :

This bug is attacked and fixed from two directions at once (as it really
looks like two bugs to me).

In version 1.1.23-1ubuntu12 of cupsys, the init script is a bit smarter
about how it tries to stop/start/restart the daemon, and should succeed
more often now.

Furthermore, in version 4.2.7-4ubuntu3 of cupsys-driver-gimpprint, even in
the even that cupsys's init script does exit with an error, which it just
plain WILL sometimes, cupsys-driver-gimpprint no longer fails to configure,
and dpkg carries on its merry way.

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

Other bug subscribers

Remote bug watches

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