Anacron doesn't work with suspend/hibernation

[Nikolaus Rath]

I have the impression that update-manager only checks for updates on startup. On my laptop, an X11 session usually lasts for several weeks because the computer is hibernated and not restarted. So far I only got update notifications after having actually have restarted the system. Either I was unlucky, or update-manager should be changed to check for upgrades in fixed intervals.

[Vassilis Pandis (pandisv)]

It does. If you go to "preferences" you can instruct update-manager to check for updates in fixed time intervals. Unless of course, this is a bug report that this feature doesn't work ....

[Nikolaus Rath (nikratio)]

According to my settings, update-manager should check daily for updates. But I have the impression that it doesn't do so... I'll pay some more attention to this in the future, but I don't really now how to pin the problem down... Is there some way to check whether update-manager ought to show something?

[Michael Vogt (mvo)]

Thanks for your bugreport.

The update-notifier uses sets its configuration in /etc/apt/apt.conf.d/10periodic for the cronjob in /etc/cron.dailey/apt. This cronjob is run by anacron.

You can check the timestamps in /var/lib/apt/periodic/ to see if the job was actually run. When it was run it will update the timestamp of the file.

Cheers,
 Michael

[Michael Vogt (mvo)]

I set the bug to "need info" for now. Please monitor the stamp files. It is possible that this is actually a bug in anacron (the system that we install for machines that are not up all day).

[Nikolaus Rath (nikratio)]

Looks like an anacron bug then:

[0] nokile:/var/lib/apt/periodic$ dir
total 0
-rw-r--r-- 1 root 0 2006-03-26 18:39 update-stamp
[0] nokile:/var/lib/apt/periodic$ date
Di Mär 28 13:49:24 CEST 2006
[0] nokile:/var/lib/apt/periodic$ uptime
 13:49:26 up 1 day, 19:17, 2 users, load average: 0.21, 0.24, 0.19
[0] nokile:/var/lib/apt/periodic$

[Rob Latham (rob-terizla)]

I have this problem on my laptop as well. Here's what I think is going on: my laptop is in standby at 7am when cron would normally kick off anacron.

In breezy, i added anacron to STOP_SERVICES in /etc/default/acpi-support. Upon resume, anacron would start. If i was still on battery, it would defer taking any action. If anacron had run less than 24 hours ago, it would do nothing. If i never sleep again, anacron will kick in as part of the 7am cron job. If i sleep and wake up on battery, anacron will run. So it's not perfect but it gets anacron running every 2-3 days at worst.

In dapper, however, /etc/acpi/sleep.sh skips all those scripts if gnome-power-manager or klaptopdaemon is running. Seems like gnome-power-manager or klaptopdaemon, if they are going to be the way dapper implements acpi policy, should at least kick off anacron. Maybe they could consult /etc/default/acpi-support for which services to start and stop when resuming or sleeping.

[Nikolaus Rath (nikratio)]

Reassigning to anacron. Hopefully this can be fixed before dapper. Especially on laptops anacron should work with hibernation.

[Rob Latham (rob-terizla)]

I've changed /etc/cron.d/anacron so that it runs every hour. /etc/init.d/anacron checks to see if we are on battery or not, so we won't run anacron jobs if we are on battery (good for laptops). Anacron checks the files in /var/spool/anacorn so even if invoked 24 times a day, daily jobs will run only one time (good for everyone).

It's not the cleanest solution but it's easy for me to understand the files in /etc/, and we get anacron running even if the machine is in console mode.

[Seb Wills (sebwills)]

It is not true that sleep.sh skips things like handling STOP_SERVICES (and all the suspend.d and resume.d entries) if gnome-power-manager or klaptopdaemon is running. The theory is that g-p-m or klaptopdaemon will see the ACPI sleep event and should itself invoke sleep.sh with the "force" parameter. Rob: are you sure anacron doesn't get invoked on resume if you add it to STOP_SERVICES in Dapper?

What I think we should do is add an entry /etc/acpi/resume.d/85-anacron.sh which contains

  #!/bin/sh
  /usr/sbin/invoke-rc.d anacron start >/dev/null

And, for completeness, a corresponding 'stop' script /etc/acpi/suspend.d/15-anacron.sh in case anacron is still running when the user suspends.

Would be great if someone running Dapper on a laptop could try that.

It would be nice to also invoke anacron whenever the AC adaptor is plugged in, as happens under APM via /etc/apm/events/anacron. However acpi-support doesn't currently contain a run-parts directory for power events.

[Seb Wills (sebwills)]

(Further to the last paragraph in my previous comment, I have filed bug #44996 about the lack of a run-parts hook for power status change events in acpi-support)

[Rob Latham (rob-terizla)]

boy do I feel stupid. The service is called 'anacron', not 'anachron'.

Suspend and resume appears to be doing the right thing. It was calling 'invoke-rc.d --quiet anachron'. there is no 'anachron' service, and the --quiet option hid the error from me.

I corrected the spelling in STOP_SERVICES and all appears back to normal.

[Seb Wills (sebwills)]

OK. And now bug #44996 is fixed, I think there is a perfect fix for this bug, which will prod anacron upon resume and also whenever the AC is plugged in. The fix is:

A script consisting of:

  #!/bin/sh
  /usr/sbin/invoke-rc.d anacron start >/dev/null

placed as /etc/acpi/resume.d/85-anacron.sh and also as /etc/acpi/ac.d/85-anacron.sh

And a script consisting of:

  #!/bin/sh
  /usr/sbin/invoke-rc.d anacron stop >/dev/null

placed as /etc/acpi/suspend.d/15-anacron.sh and also as /etc/acpi/battery.d/15-anacron.sh.

I will file an upstream bug (suggesting this fix) for the anacron debian package in a few days, once the acpi-support package has appeared in Debian (it's currently sitting in incoming). In the mean time, anyone able to get it into Dapper?

[Rob Latham (rob-terizla)]

<i> What I think we should do is add an entry
 /etc/acpi/resume.d/85-anacron.sh which contains

#!/bin/sh
/usr/sbin/invoke-rc.d anacron start >/dev/null

 And, for completeness, a corresponding 'stop' script
/etc/acpi/suspend.d/15-anacron.sh in case anacron is still running when the user suspends.
</i>

I've added these scripts to my dapper-running laptop and removed anacron from STOP_SERVICES. anacron defers execution when resuming and on battery, runs when it should. I'll keep using them for the next few days and report back on how it went. Sure does seem like the right solution, though I left off the redirect to /dev/null.

[Michael Vogt (mvo)]

@ubuntu-laptop team: does the proposed change for anacron in /etc/apci/resume.d look ok to you? I target this for dapper and set it to "major" because of the potential security implications.

[Matthew Garrett (mjg59)]

Looks fine to me - that's why I added the support.

[Florian Boucault (fboucault)]

Remark: Debian bug #202605 reports similar issues with Macs and pmud.

Have a nice day :)

[Michael Vogt (mvo)]

I uploaded a new version of anacron into edgy today. If that version works well we can backport it to dapper.

[Philipp Kohlbecher (xt28)]

This bug still occurs in dapper.

[JC Hulce (soaringsky)]

Thank you for reporting this bug to Ubuntu. The version of Ubuntu referenced in this issue has reached end of life, and the issue is fixed in newer versions of Ubuntu.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

[caspar_wrede (caspar-wrede)]

I believe this bug still exists in 12.04.

Running "sudo run-parts --report /etc/cron.daily"
causes the script to hang at
run-parts: executing /etc/cron.daily/apt

[Rüdiger Kupper (ruediger.kupper)]

Caspar, what you see is not a bug it's a feature :-).
/etc/cron.daily/apt is set to sleep for a random time (approx. 30 min) before executing. You can see this if you turn on debug messages. Put the following line into /etc/apt/apt.conf.d/10periodic:
APT::Periodic::Verbose "1";

[Rüdiger Kupper (ruediger.kupper)]

Interestingly, this has the side effect of delaying execution of all other scripts in /etc/cron.daily after "apt" (in lexical sort order). I wonder if this is intended. If it is, the sleep command should probably not be part of the "apt" script but put in a separate script.
And id it is not intended, run-parts should not need to wait for the "apt" script to finish, befor it can call the other scripts.