On Thu, Nov 09, 2006 at 04:14:43AM -0800, Steve Langasek wrote:
> On Thu, Nov 09, 2006 at 10:49:53AM +0100, Lionel Elie Mamane wrote:
>> This code:
>> if dpkg --compare-versions "$2" lt-nl 1.21-3 ; then
>> mv /etc/chrony/chrony.keys."$2" /etc/chrony/chrony.keys
>> mv /etc/chrony/chrony.conf."$2" /etc/chrony/chrony.conf
>> fi
>> in the postinst makes the postinst not idempotent, and makes my chrony
>> fail to configure:
> Idempotency is not a release-critical requirement per se.
OK.
> Can you comment on why this code failed for you at all?
I'm not sure. The code assumes that when upgrading from version
earlier than 1.21-3, you *must* have a
/etc/chrony/chrony.keys.${OLD_VERSION} file. I've never noticed any
file with that name on my systems from woody times up to now, but I
may just not have seen them. Maybe these are files that an older
version *may* have left behind but does not necessarily leave behind?
Which would give a different reason than idem-potency for this to be a
bug.
I actually doubt that *all* past versions left such files, but maybe
all since sarge and maintainer made a conscious decision not to
support earlier-than-sarge upgrades (which we don't support in
general).
> Did the postinst script in fact run twice, and fail with a
> *different* problem the first time through?
I don't know. I didn't touch that machine in some weeks, and now
aptitude told me:
dpkg was interrupted, please run dpkg --configure -a
I did that, many packages got configured, and configuration of chrony
failed. Maybe I had left an earlier upgrade session in a "screen"
session, forgot about it and then rebooted the machine at a later
time, interrupting dpkg brutally. Or I had an upgrade session in a SSH
session which died, which SIGHUP-killed the running dpkg. Yes, that
looks like a plausible scenario.
> The only lines after this in the postinst are:
> ucf --sum-file /usr/share/chrony/chrony.conf.md5sum
> /etc/chrony/chrony.conf.new /etc/chrony/chrony.conf
Complementing the above scenario, it is plausible that dpkg/ucf would
have been interrupted when ucf was waiting for my input (changes in
config files, what shall be done? package version / your version /
merge / show differences / ...). On non-critical and slow machines
(such as this one), I often start an upgrade, leave it running and
come back a few hours/days later to find dpkg/ucf/debconf waiting for
my input.
In this scenario, the root cause of the failure is indeed the lack of
idem-potency in itself.
> rm /etc/chrony/chrony.conf.new
> invoke-rc.d chrony start
> Idempotency is only an issue if one of these lines fails, since
> otherwise the postinst will complete successfully the first time and
> never again be called with the same arguments. Thus I think
> identifying the underlying failure on your system is at least as
> important as making the mv commands more robust.
I replaced the lines as in my suggestion, reran "dpkg --configure
--pending", and configuration succeeded, with ucf asking me a
question, which is compatible with above scenario, but also with the
files not existing in the first place.
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
