Ubuntu does not automatically check for updates, even when set to

Bug #390319 reported by Aaron Kelley on 2009-06-21
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
update-notifier (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: update-notifier

I have two machines with this problem. This shouldn't be happening, so I am calling it a bug.

One of them is running the desktop version of Ubuntu 9.04. I have set it in the Software Sources admin applet to "Check for updates daily" and "Download all updates in the background." It never offers updates to me. But if I go to the terminal and "sudo aptitude update," updates are offered via the GUI right away. So, it seems that whatever process in the background is supposed to check for updates periodically is not working.

Another machine running the server version of Ubuntu 9.04. I have it set to check daily install security updates automatically. It also never finds updates automatically --- if I connect via SSH it tells me 0 updated packages are available, and security updates are never installed automatically. I have to make sure to connect and install updates manually from time to time.

Please let me know what I can do to help track this problem down.

Disclaimers:

Both of these machines were upgraded from Ubuntu 8.10. Both of them properly checked for updates before the upgrade to 9.04, and have been displaying this problem since the very moment 9.04 was released.

I am aware of the new update notification system in 9.04 (security updates daily, other updates weekly, no tray icon, etc.). This is not the problem here. I left town for two weeks and left both machines on to check, neither of them offered any updates automatically, but as soon as I returned and did a "sudo aptitude update" there were 60+ updates available on the desktop machine, many of them security updates that should have been detected by the daily check.

I'm not sure if the method used to upgrade from 8.10 would make any difference, but it is the only thing I can think of that is different between my machines. What I mean is, these two machines that do not check for updates automatically were updated from 8.10 with the command-line method ("do-release-upgrade"). I have a third machine upgraded with the GUI method and it is handling automatic update checking beautifully.

Thank you!

Aaron Kelley (aaronkelley) wrote :

Found the problem (I think).

The /etc/cron.daily/apt script, which I believe handles the automatic update setting, was not marked executable on either machine.

This reveals two problems:

 - /etc/cron.daily/apt lost its executable status during the do-release-upgrade process (I'm quite sure I didn't change the permissions on that file myself)
 - The GUI for configuring the automatic update interval should check this and warn you if this script is not executable! (Or just fix it itself.)

Michael Vogt (mvo) wrote :

Thanks for your bugreport.

I fixed software-properties to ensure that the cron job is executable now. Could you please attach the logs from you upgrades (/var/log/dist-upgrade/*) so that I can check if there is any hint there ?

Changed in update-notifier (Ubuntu):
status: New → Incomplete
Aaron Kelley (aaronkelley) wrote :

Here you are... dist-upgrade logs from two affected machines.

WhyteHorse (whytehorse) wrote :

Confirmed. My /etc/cron.daily/apt wasn't marked executable as well. I upgraded from 8.10 to beta and then to 9.04. I had all kinds of problems and one of the last ones I've been looking into was this. Same behaviour as the original post. We'll see if this fixes it. Attached are my upgrade logs too.

There is no cron.weekly for apt.

Jacques Luder (j-luder) wrote :

I have exactly the same problem. /etc/cron.daily/apt not executable after a upgrade to 9.04.
I join a tar of my dist-upgrade. Note at first upgrade fail, reason is the use of gettext 0.15 i forgot to uninstall before upgrade.

Chris Thomas (CTho) (cst-yecc) wrote :

I had the same problem.

/var/log/dist-upgrade/20090625-1834/main.log (to 9.04?) contains:
2009-02-07 16:37:45,999 DEBUG disabling apt cron job (0100755)
2009-02-07 20:49:12,595 DEBUG enabling apt cron job

/var/log/dist-upgrade/20091213-2027/main.log (to 9.10?) contains:
2009-06-25 19:37:59,096 DEBUG disabling apt cron job (0100755)
...but doesn't contain a corresponding "enabling" message.

Ernst Sjöstrand (ernstp) wrote :

This happened to me also on my webserver, stopped unattended-upgrades from working.
It seems to me that fixing this in software-properties is not enough.

Launchpad Janitor (janitor) wrote :

[Expired for update-notifier (Ubuntu) because there has been no activity for 60 days.]

Changed in update-notifier (Ubuntu):
status: Incomplete → Expired
Lex Ross (lross) wrote :

Same thing had happened to me while upgrading from 10.10 to 11.04
Yet another bug propagating from one release to another.

The exact same bug occurred to me when updating from 12.04 to 12.10.
On my machine also /etc/cron.daily/apt is not set executable.

So, I think, unfortunately the bug still exists?!

Changed in update-notifier (Ubuntu):
status: Expired → Confirmed

I got this bug in one of my machines when updating to 13.04, but not in other machines I updated. It turns out that the machine affected is behind a proxy, which is working as expected. Could it be related? Anybody else with this problem behind a proxy, or are there other cases completely unrelated to the proxy?

Aaron Kelley (aaronkelley) wrote :

My original issue was unrelated to proxy settings. The machines in question were not behind a proxy. The problem here was related to /etc/cron.daily/apt not being marked "executable" after an upgrade --- as far as I know, no one has figured out why this happens, but it is easy enough to resolve manually.

Thanks aaronkelley, yes, for me the issue was exactly the same, I just wanted to check if the fact that /etc/cron.daily/apt lost the executable flag was related to the proxy, as it happened to me for that machine but not for others that I upgraded. I was investigating in debian bugs if I could find something related, but I couldn't find anything, and a search did not produce anything for other distros, so it seems this is something caused by ubuntu.

Brian Murray (brian-murray) wrote :

I found a case in update-manager where this might have occurred but it was quite some time ago:

 $ bzr log -r 1124
------------------------------------------------------------
revno: 1124
committer: Michael Vogt <email address hidden>
branch nick: main
timestamp: Wed 2008-10-15 18:55:42 +0200
message:
  DistUpgrade/DistUpgradeController.py:
  - reenable cron job on failed downloads too

Walter could you attach the log files from your upgrade,? You'll find them in /var/log/dist-upgrade as they might help find another case where the cronjob's status is not returned.

Changed in update-notifier (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Brian Murray (brian-murray) wrote :

The fix referenced in the previous bzr log definitely exists in quantal and raring.

FIles from my /var/log/dist-upgrade directory

Now that I remember, when I was upgrading this machine to 13.04, my system partition was running out of space, and I don't know what I was thinking but I issued a "apt-get clean" in the middle of the upgrading process. This obviously aborted the upgrade and I had to finish it "manually", this may show up in the logs above. Maybe this is what caused in my case the non-executable flag of "/etc/cron.daily/apt".

Brian Murray (brian-murray) wrote :

Walter, yes interrupting the upgrade would cause the upgrader to quit abnormally and probably prevent it from reenabling the cronjob. Having said that I did find a system of mine where the cronjob was disabled and I'll investigate it some more to see if there are any more corner cases.

Brian Murray (brian-murray) wrote :

Actually, my machine has never been upgraded so the job was disabled upon install.

Brian Murray (brian-murray) wrote :

I tried a fresh raring install and the apt cron.daily job was not disabled so perhaps it was something with the Alpha install of raring I did. I'm going to set this to Invalid since there don't seem to be any cases where this is happening anymore.

Changed in update-notifier (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers