samba postrm depends on packages not guaranteed to be configured

Bug #862129 reported by Till Kamppeter
This bug affects 153 people
Affects Status Importance Assigned to Milestone
samba
Fix Released
Unknown
perl (Debian)
Fix Released
Unknown
perl (Ubuntu)
Fix Released
High
Colin Watson
Oneiric
Won't Fix
Undecided
Unassigned
Precise
Fix Released
High
Colin Watson
update-inetd (Debian)
Fix Released
Unknown
update-inetd (Ubuntu)
Fix Released
High
Colin Watson
Oneiric
Won't Fix
Undecided
Unassigned
Precise
Fix Released
High
Colin Watson
update-manager (Ubuntu)
Invalid
High
Unassigned
Oneiric
Won't Fix
High
Michael Vogt
Precise
Invalid
High
Unassigned

Bug Description

Continued the installation of bug 862119, doing "sudo apt-get install -f" and then "sudo apt-get upgrade" again. After some time this bug occured.

ProblemType: Package
DistroRelease: Ubuntu 11.04
Package: samba 2:3.5.8~dfsg-1ubuntu2.3
ProcVersionSignature: Ubuntu 2.6.38-11.50-generic 2.6.38.8
Uname: Linux 2.6.38-11-generic i686
Architecture: i386
Date: Thu Sep 29 10:02:27 2011
ErrorMessage: subprocess new post-removal script returned error exit status 2
RelatedPackageVersions:
 nautilus 1:3.2.0-0ubuntu2
 gvfs 1.8.0-0ubuntu3
SambaClientRegression: Yes
SourcePackage: samba
Title: package samba 2:3.5.8~dfsg-1ubuntu2.3 failed to install/upgrade: subprocess new post-removal script returned error exit status 2
UpgradeStatus: Upgraded to natty on 2011-07-13 (77 days ago)

Related branches

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The postrm script needs perl-modules. An appropriate dependency should be defined.

Changed in samba (Ubuntu):
milestone: none → ubuntu-11.10
importance: Undecided → High
Revision history for this message
Colin Watson (cjwatson) wrote :

No, that's not quite right. Per policy (http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact):

  The package whose postrm is being called may have previously been deconfigured and only be unpacked, at which point subsequent package changes do not consider its dependencies. Therefore, all postrm actions may only rely on essential packages and must gracefully skip any actions that require the package's dependencies if those dependencies are unavailable.

In any case, samba already depends on update-inetd, which depends on libfile-temp-perl, which is provided by perl-modules, so it's clearly not a matter of adding a dependency. It does have some code to attempt to gracefully cope if update-inetd is missing, but (a) the check for update-inetd being present isn't there in all branches, and (b) in this case update-inetd is present but not all its dependencies are available.

Changed in samba (Ubuntu):
status: New → Triaged
Robie Basak (racb)
summary: - package samba 2:3.5.8~dfsg-1ubuntu2.3 failed to install/upgrade:
- subprocess new post-removal script returned error exit status 2
+ samba postrm depends on packages not guaranteed to be configured
Revision history for this message
Robie Basak (racb) wrote :

I'm thinking along the lines of the attached patch (untested). Some questions:

1) Is this the right approach?
2) Is dpkg-query the right way to get the status of the update-inetd package?
3) What about triggers-awaiting and triggers-pending? What should the behaviour be in these cases? Is it OK to treat update-inetd as not available in these cases?
4) I've tried manually deconfiguring update-inetd and perl-modules (by purging and then unpacking only) before purging samba, but that doesn't trigger the problem. Any way I try the upgrade case, dpkg refuses because update-inetd (intentionally) isn't configured. Is there any way I can reproduce this reliably?

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Untested patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Robie Basak (racb) wrote :

The attached script reproduces the problem on a minimal fresh oneiric install.

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

Surely, we can just move the update-inetd call to prerm? I can't imagine why you'd want to wait around for postrm before calling it anyway.

Changed in samba:
status: Unknown → New
Steve Langasek (vorlon)
Changed in samba (Ubuntu):
milestone: ubuntu-11.10 → oneiric-updates
Revision history for this message
Steve Langasek (vorlon) wrote :

Historically, we wait for postrm before calling update-inetd --remove because the enabled/disabled status of an inetd service is admin configuration data, so we only want to remove it on purge.

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

I catch your point, Steve, but doesn't it seem silly to have an enabled service in inted that references binaries that no longer exist on disk?

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

And it occurs to me that I maintain a package that calls update-inetd in postrm too. Hrm. Did it used to fail more gracefully when it wasn't fully configured? This may need a more general looking-at rather than just samba (though I do find it curious that samba users in particular seem to so frequently remove perl-modules after removing samba).

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

Or is this being triggered by upgrading/mangling samba in the middle of perl transitions? I think I need to look more deeply into the dupes and see what's going on here, cause I refuse to believe a ton of people are doing this "on purpose".

Revision history for this message
Steve Langasek (vorlon) wrote :

> but doesn't it seem silly to have an enabled service in inetd
> that references binaries that no longer exist on disk?

Well, it's possible to use a different marker for package-level disabling vs. admin-level disabling of a service... note that the postrm *always* disables it when we're not purging, too.

Anyway, I'm not sure we ever executed very well on this, just explaining how we got here.

Dave Walker (davewalker)
tags: added: regression-release
Dave Walker (davewalker)
Changed in samba (Ubuntu Oneiric):
status: New → Triaged
importance: Undecided → High
milestone: none → oneiric-updates
Changed in samba (Ubuntu Precise):
milestone: oneiric-updates → precise-alpha-1
Revision history for this message
Robie Basak (racb) wrote :

I discussed this bug at length with Adam on Friday afternoon. Adam is on vacation now so I'll try and reproduce my memory and conclusions from this conversation.

Some thoughts from that discussion:

1) perl-modules (which provides File::Temp) seems to spend a lot of time unconfigured in the upgrade process. Adam pointed out that this is an anomaly given how much packages depend on Perl in general, and that the problem might be considered to be with the Perl transition and fixing this may be one approach. Take a look at VarLogDistupgradeTermlog.gz in bug 856309 for example - perl and perl-modules are unpacked but not configured in the entire session. I understand that this still complies with policy; the way I see the problem is that perl-modules and update-inetd still need to export some kind of mechanism to make them usable within maintainer scripts for them to be useful.

2) If update-inetd is supposed to be able to be used from within maintainer scripts, what is the correct way of doing so? If it is supposed to be used from a postrm and thus cannot rely on perl-modules to be configured, then is the bug really that update-inetd is depending on things that it cannot?

3) If we could change update-inetd to not depend on Perl modules that may not be configured, then this particular bug wouldn't be an issue any more. It looks like we may only need tempfile anyway, which is in debianutils and Essential. The advantage of File::Temp seems to be portability, which isn't an issue for us as we guarantee tempfile to always be available. update-inetd also appears to need File::Copy so I'll need to check this, but in any case would the approach of removing dependencies by bringing minimal implementations into update-inetd be acceptable?

tags: added: rls-mgr-p-tracking
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Given the number of dupes, shouldn't this be raised to a Critical level? This has now broken dozens of upgrades that we know about, and I'm sure many more that haven't bothered to report it.

Robie's suggestion to simplify update-inetd, given that these are very primitive elements, seems the best approach for a quick fix while the nature of the dependency problem is considered.

Revision history for this message
Steve Langasek (vorlon) wrote :

Analysis of the upgrade logs and further discussion on IRC shows that it's infeasible to fix this in samba. The problem arises when perl-modules is unpacked without libperl5.12/perl-base, and then samba is unpacked. Moving the update-inetd code from the postrm to the prerm may help in some cases, but not in this one, because whichever maintainer script tries to call update-inetd, the modules will be unavailable to perl at that point.

Fixing update-inetd to be more robust (i.e., to not require perl-modules) would help for the future, but would not help for the present upgrade problems.

I think the only way to fix this reliably is via update-manager.

affects: samba (Ubuntu Oneiric) → update-manager (Ubuntu Oneiric)
Changed in update-manager (Ubuntu Oneiric):
assignee: nobody → Michael Vogt (mvo)
Steve Langasek (vorlon)
tags: added: rls-p-tracking
Revision history for this message
Dave Walker (davewalker) wrote :

bug 877852 is a secondary tracking bug.

Steve Langasek (vorlon)
Changed in update-inetd (Ubuntu Precise):
milestone: none → ubuntu-12.04
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Colin Watson (cjwatson)
Changed in update-inetd (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
milestone: ubuntu-12.04 → precise-alpha-1
Revision history for this message
Colin Watson (cjwatson) wrote :

I've suggested a patch to update-inetd to make it tolerate perl-base/perl-modules desync, and an added Breaks in perl-base to match this; see the linked Debian bug reports. I think that if we did this we could avoid needing to change update-manager, since apt would install the improved update-inetd first (even just unpacking it would be enough). We could SRU update-inetd and perl for this.

Steve, Michael, do you agree with this assessment?

Changed in update-inetd (Ubuntu Precise):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-inetd - 4.41

---------------
update-inetd (4.41) unstable; urgency=low

  * Fall back to external 'tempfile' and 'mv' commands in case perl-base and
    perl-modules are out of sync during an upgrade (Closes: #649174;
    LP: #862129). Thanks to Colin Watson <email address hidden> for the bug
    report and patch.

 -- Serafeim Zanikolas <email address hidden> Tue, 22 Nov 2011 23:15:02 +0100

Changed in update-inetd (Ubuntu Precise):
status: Triaged → Fix Released
Changed in perl (Debian):
status: Unknown → New
Changed in update-inetd (Debian):
status: Unknown → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

I'd prefer to fix this in update-inetd + perl rather than update-manager for alpha-1, as discussed.

Changed in perl (Ubuntu Precise):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
milestone: none → precise-alpha-1
status: New → Triaged
Changed in update-manager (Ubuntu Precise):
status: Triaged → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package perl - 5.14.2-5ubuntu1

---------------
perl (5.14.2-5ubuntu1) precise; urgency=low

  * Break older versions of update-inetd to avoid File::Temp and File::Copy
    binary-incompatibility issues during upgrades (LP: #862129).
 -- Colin Watson <email address hidden> Thu, 24 Nov 2011 15:24:30 +0000

Changed in perl (Ubuntu Precise):
status: Triaged → Fix Released
Changed in perl (Debian):
status: New → Fix Committed
Changed in perl (Debian):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in perl (Ubuntu Oneiric):
status: New → Confirmed
Changed in update-inetd (Ubuntu Oneiric):
status: New → Confirmed
Revision history for this message
Blair Chasteen (darkstormyrain) wrote :
Download full text (5.0 KiB)

perl-modules: /usr/share/perl/5.12.4/File/Temp.pm

darkrain@vortex:~$ dpkg -s perl-modules update-inetd
Package: perl-modules
Status: install ok unpacked
Priority: standard
Section: perl
Installed-Size: 24832
Maintainer: Ubuntu Developers <email address hidden>
Architecture: all
Source: perl
Version: 5.12.4-4
Config-Version: 5.10.1-17ubuntu4.1
Replaces: libansicolor-perl, libarchive-tar-perl, libattribute-handlers-perl, libautodie-perl, libcgi-pm-perl, libclass-isa-perl, libcpanplus-perl, libdigest-perl, libextutils-cbuilder-perl, libextutils-command-perl, libextutils-install-perl, libextutils-parsexs-perl, libfile-path-perl, libfile-spec-perl, libfile-temp-perl, libi18n-langtags-perl, libio-zlib-perl, liblocale-codes-perl, liblocale-maketext-perl, liblocale-maketext-simple-perl, libmath-bigint-perl, libmath-complex-perl, libmodule-build-perl, libmodule-corelist-perl, libmodule-load-conditional-perl, libmodule-load-perl, libmodule-pluggable-perl, libnet-perl, libnet-ping-perl, libparams-check-perl, libparent-perl, libparse-cpan-meta-perl, libperl4-corelibs-perl, libpod-escapes-perl, libpod-parser-perl, libpod-plainer-perl, libpod-simple-perl, libshell-perl, libswitch-perl, libtest-harness-perl, libtest-simple-perl, libthread-queue-perl, libtime-local-perl, libunicode-collate-perl, libversion-perl, podlators-perl
Provides: libansicolor-perl, libarchive-tar-perl, libattribute-handlers-perl, libautodie-perl, libcgi-pm-perl, libcpanplus-perl, libdigest-perl, libextutils-cbuilder-perl, libextutils-command-perl, libextutils-install-perl, libextutils-parsexs-perl, libfile-path-perl, libfile-spec-perl, libfile-temp-perl, libi18n-langtags-perl, libio-zlib-perl, liblocale-codes-perl, liblocale-maketext-perl, liblocale-maketext-simple-perl, libmath-bigint-perl, libmath-complex-perl, libmodule-build-perl, libmodule-corelist-perl, libmodule-load-conditional-perl, libmodule-load-perl, libmodule-pluggable-perl, libnet-perl, libnet-ping-perl, libparams-check-perl, libparent-perl, libparse-cpan-meta-perl, libperl4-corelibs-perl, libpod-escapes-perl, libpod-parser-perl, libpod-simple-perl, libshell-perl, libtest-harness-perl, libtest-simple-perl, libthread-queue-perl, libtime-local-perl, libunicode-collate-perl, libversion-perl, podlators-perl
Depends: perl (>= 5.12.4-1)
Recommends: libswitch-perl, libpod-plainer-perl, libclass-isa-perl
Breaks: libansicolor-perl (<< 2.02), libarchive-tar-perl (<< 1.54), libattribute-handlers-perl (<< 0.87), libautodie-perl (<< 2.06.01), libcgi-pm-perl (<< 3.49-1squeeze1), libclass-isa-perl (<< 0.36), libcpanplus-perl (<< 0.90), libdigest-perl (<< 1.16), libextutils-cbuilder-perl (<< 0.2700), libextutils-command-perl (<< 1.16), libextutils-install-perl (<< 1.55), libextutils-parsexs-perl (<< 2.210000), libfile-path-perl (<< 2.08.01), libfile-spec-perl (<< 3.3101), libfile-temp-perl (<< 0.22), libi18n-langtags-perl (<< 0.35-1), libio-zlib-perl (<< 1.10), liblocale-codes-perl (<< 2.07), liblocale-maketext-perl (<< 1.14), liblocale-maketext-simple-perl (<< 0.21), libmath-bigint-perl (<< 1.89.01), libmath-complex-perl (<< 1.56), libmodule-build-perl (<< 0.360300), libmodule-corelist-perl (<< 2.50), libmodule-load-...

Read more...

Changed in samba:
status: New → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

Changed in update-manager (Ubuntu Oneiric):
status: Triaged → Won't Fix
Rolf Leggewie (r0lf)
Changed in update-inetd (Ubuntu Oneiric):
status: Confirmed → Won't Fix
Changed in perl (Ubuntu Oneiric):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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