Update manager shows warning that system was not updated for a long time (not true)

Bug #188127 reported by Evgeny Kuznetsov
28
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Invalid
Medium
Michael Vogt

Bug Description

Binary package hint: update-manager

After updating packages list (via either apt-get update, aptitude update, Synaptic or Update Manager), Update Manager still shows that the package information was last updated a long time ago (90 days and still increasing), and after some time shows the corresponding notification in GNOME system tray.

This problem was first introduced on my system after Gutsy-to-Hardy update, and still persists.

The system in question is Ubuntu Hardy Development Branch with latest updates installed. Update Manager is 0.87.4.

Related branches

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

Can you please attach the output of:
$ ls -l /var/lib/apt/periodic
and
$ cat /etc/apt/apt.conf.d/15update-stamp

Changed in update-manager:
status: New → Incomplete
Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

$ ls -l /var/lib/apt/periodic
total 0
-rw-r--r-- 1 root root 0 2007-10-28 07:35 update-stamp
$ cat /etc/apt/apt.conf.d/15update-stamp
APT::Update::Post-Invoke:: {"touch /var/lib/apt/periodic/update-stamp 2>/dev/null || true";};

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

And yes, manually touching /var/lib/apt/periodic/update-stamp resolves Manager's behaviour, Yet this update-stamp isn't touched automatically after "aptitude update" or the similar.

Revision history for this message
Michael Vogt (mvo) wrote :

If you use aptitude, then this explains the problem. It does currently not support the "APT::Update::Post-Invoke" hook. I will add it in the very near future.

Thanks,
 Michael

Revision history for this message
Michael Vogt (mvo) wrote :

Just to confirm, you always ran "aptitude update" (not the synaptic update, not the update-manager update)?

Changed in update-manager:
assignee: nobody → mvo
milestone: none → hardy-alpha-5
status: Incomplete → Confirmed
Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

I generally use aptitude, that's right (though I use it since Ubuntu 6.06 and never had such a problem). But after I started suffering from this bug, I have tested update-manager and apt-get update as well — none of them updates the timestamp. One minute ago I have also tested Synaptic with same result.

Michael Vogt (mvo)
Changed in update-manager:
importance: Undecided → Medium
status: Confirmed → In Progress
Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for this bugreport and the good description. This should be fixed with the next apt upload. Please let me know if it works for you then (aptitude is not yet fixed, but apt, synaptic, update-manger should be fine).

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

I need more time for testing, but right now it looks like the timestamp is updated only if there actually are updates available, and only by update-manager (not by apt-get, never speaking of aptitude, of course). Don't consider this message as a report, I'll go on testing for a couple of days more.

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

Now, this becomes more and more funny. Neither apt-get, nor update-manager update the timestamp when I invoke apt-get update or click "update" in update-manager manually. At the same time, update-manager seems to be updating the timestamp every morning during automatic search for updates.

The funniest thing is, update-manager has updated the timestamp today at 7:35 AM (it always checks for update at approximately this time. The trouble is, the laptop was connected to the router, but router was not connected to the Internet at that time! I've unplugged the ISP cable from router at 10 PM yesterday, and plugged it back at 1 PM today, so there was absolutely no chance for update-manager to fetch updates at 7:35 AM — but the timestamp says it did...

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

This bug was fixed in the upload of apt 0.7.9ubuntu11. Changelog:

apt (0.7.9ubuntu11) hardy; urgency=low

  * apt-pkg/algorithms.cc:
    - add APT::Update::Post-Invoke-Success script slot
      (LP: #188127)

 -- Michael Vogt <email address hidden> Thu, 10 Jan 2008 12:06:12 +0100

... don't ask me why the date in the changelog is what it is, that date is before the bug in question was even filed. :)

Changed in update-manager:
status: In Progress → Fix Released
Revision history for this message
Michael Vogt (mvo) wrote :

@Evgeny: Could you please give me the output of ls -l /var/lib/apt/periodic ? You need to check for the file /var/lib/apt/periodic/update-success-stamp - the update-stamp is just for the daily auto-update and does not tell if the update actually happend, just that it was tried.

Cheers,
 Michael

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

Michael, there's no /var/lib/apt/periodic/update-success-stamp on my system, only update-stamp is in the directory.

apt is version 0.7.9ubuntu12

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

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

Thank you, Vojtěch, you're totally right! I think the reason for this behaviour is obvious and sensible, so this bug should be treated as invalid.

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

There is an option to check for only for failures on official repositories. No matter about third party. It seems to me better solution. But It would be harder to implement, I think. It's also true, that unofficial repositories could be more important than official ones.

This bug occurs only to people adding some unreliable repositories. So the easiest solution seems to be the best one. I agree with what Evgeny wrote: "... this bug should be treated as invalid."

Changed in apt:
status: Fix Released → Invalid
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.