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]