Comment 14 for bug 188127

Revision history for this message
Vojtěch Látal (vojtik) wrote :

Similar problem here. But I use generally synaptic and update-manager through update-notifier applet.

$ ls -l /var/lib/apt/periodic
total 0
-rw-r--r-- 1 root root 0 2008-05-07 00:46 download-upgradeable-stamp
-rw-r--r-- 1 root root 0 2008-04-29 07:53 update-stamp
-rw-r--r-- 1 root root 0 2008-04-29 09:05 update-success-stamp
-rw-r--r-- 1 root root 0 2008-05-07 00:46 upgrade-stamp

$ cat /etc/apt/apt.conf.d/15update-stamp
APT::Update::Post-Invoke-Success:: {"touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";};

My theory is that 'touch /var/lib/apt/periodic/update-success-stamp' is executed only when no problem occurs while downloading package information. No matter if it was invoked by Synaptic's Update button or by update-notifiers 'Check for updates' option. I had some third party repositories added. Sometimes repository indexes are fetched without any problem, sometimes they don't because of timeout (or maybe they don't exist yet - hardy is just released).

Yess. My theory seems to be correct. When just one of the repository indexes fails to be fetched, that file isn't touched. I tried to disable repository which is having this problem. Voila. Command 'touch /var/lib/apt/periodic/update-success-stamp' gets executed after 'Check for updates'.

Signature of repository needn't to be verified, but repository index must be fetched.

This behavior can be reproduced by clicking Cancel while downloading repository indexes (update information).

After disabling repository which was failing:
$ ls -l /var/lib/apt/periodic
total 0
-rw-r--r-- 1 root root 0 2008-05-07 00:46 download-upgradeable-stamp
-rw-r--r-- 1 root root 0 2008-04-29 07:53 update-stamp
-rw-r--r-- 1 root root 0 2008-05-07 19:10 update-success-stamp
-rw-r--r-- 1 root root 0 2008-05-07 00:46 upgrade-stamp