samba postrm depends on packages not guaranteed to be configured

[Till Kamppeter]

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)

[Till Kamppeter (till-kamppeter)]

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

[Colin Watson (cjwatson)]

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.

[Robie Basak (racb)]

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?

[Ubuntu Foundations Team Bug Bot (crichton)]

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

[Robie Basak (racb)]

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

[Adam Conrad (adconrad)]

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.

[Steve Langasek (vorlon)]

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.

[Adam Conrad (adconrad)]

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?

[Adam Conrad (adconrad)]

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

[Adam Conrad (adconrad)]

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

[Steve Langasek (vorlon)]

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

[Robie Basak (racb)]

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?

[Clint Byrum (clint-fewbar)]

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.

[Steve Langasek (vorlon)]

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.

[Dave Walker (davewalker)]

bug 877852 is a secondary tracking bug.

[Colin Watson (cjwatson)]

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?

[Launchpad Janitor (janitor)]

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

[Colin Watson (cjwatson)]

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

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Blair Chasteen (darkstormyrain)]

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

[Rolf Leggewie (r0lf)]

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