Bug 464393 - at daemon sleeps too long after a resume from S3 standby/suspend
at daemon sleeps too long after a resume from S3 standby/suspend
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-28 00:15 EDT by Kieran Clancy
Modified: 2012-05-10 10:24 EDT (History)
1 user (show)

See Also:
Fixed In Version: at-3.1.13-6.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-10 10:24:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Use POSIX timers (2.65 KB, patch)
2011-11-16 16:39 EST, Matthew Garrett
no flags Details | Diff
Use POSIX timers (2.69 KB, patch)
2011-11-16 16:42 EST, Matthew Garrett
no flags Details | Diff

  None (edit)
Description Kieran Clancy 2008-09-28 00:15:31 EDT
Description of problem:
The at daemon sleeps for 3600 seconds at a time if there is no task to run in the next hour. If during this, the computer is suspended to RAM, when it resumes, the kernel will continue the nanosleep, sleeping for the remaining (up to 3600) seconds.

The problem is, if there is a task scheduled in the minutes after the resume, they will usually be run late. In my case I use 'at' to schedule my alarm clock, then use the rtc alarm function of my BIOS to wake the computer a couple of minutes before my alarm goes off. If atd sleeps for almost an hour past this desired time, it's not a very effective method.

Is there some way to patch atd so that it gets some kind of signal on a resume from suspend (I imagine the problem also occurs with hibernate). Alternatively, is there a sleep call that attempts to sleep in wall time (if such a system call exists) -- that is, sleep until this many seconds past Jan 01 1970, as oppose to sleep for x seconds; this would mean the sleep would finish just after resume, as the wall time would be well and truly past what it should be?

As a current workaround, I have put the following script in /etc/pm/sleep.d/signal_atd:
#!/bin/sh
# When resuming, send atd a SIGHUP to recalculate sleep timer

if [ "$1" == "resume" -a -f /var/run/atd.pid ]; then
	pid=`cat /var/run/atd.pid`
	if [ -d "/proc/$pid" ]; then
		kill -HUP "$pid"
	fi
fi

Version-Release number of selected component (if applicable):
at-3.1.10-23.fc9.i386

How reproducible:
Very.

Steps to Reproduce:
1. Schedule a job using 'at' for the current time plus 65 minutes
2. Suspend the system for 10 minutes (or more), then resume
3. Check what time the job runs.
  
Actual results:
The job is run at least 5 minutes later than it should have. If you suspended the system for 60 minutes at step 2, it would have run the job almost 60 minutes late.


Expected results:
If the system is running, run the requested jobs at the right time. So, given that the system is no longer in suspend, it should be able to service requests as usual.


Additional info:
An strace -t -T gives something like:
04:09:47 nanosleep({3600, 0}, 0xbf84c4e4) = ? ERESTART_RESTARTBLOCK (To be restarted) <31763.781788>
12:59:11 restart_syscall(<... resuming interrupted call ...>) <3496.452345>
Comment 1 Marcela Mašláňová 2008-10-02 08:59:32 EDT
Thank you for your report. I didn't notice problem with suspend/hibernation is also in this daemon.

I rewrote your script into pm-utils (in /usr/lib/pm-utils/sleep.d/56atd) and it's also working for me. I'll be testing for a while this solution.
Comment 2 Fedora Update System 2008-12-03 09:23:04 EST
at-3.1.10-25.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/at-3.1.10-25.fc9
Comment 3 Fedora Update System 2008-12-06 23:21:44 EST
at-3.1.10-25.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update at'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10818
Comment 4 Fedora Update System 2008-12-09 23:34:44 EST
at-3.1.10-25.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Matthew Garrett 2011-11-16 16:39:36 EST
Created attachment 534100 [details]
Use POSIX timers

This changes at to use absolute POSIX timers. These should fire immediately on resume if they've expired.
Comment 6 Matthew Garrett 2011-11-16 16:42:30 EST
Created attachment 534102 [details]
Use POSIX timers

This version builds even when POSIX timers aren't available.
Comment 7 Marcela Mašláňová 2011-11-21 08:53:10 EST
I'll review it and test. Thanks.
Comment 8 Fedora Update System 2012-04-20 09:40:48 EDT
at-3.1.13-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/at-3.1.13-6.fc16
Comment 9 Fedora Update System 2012-04-20 09:42:31 EDT
at-3.1.13-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/at-3.1.13-8.fc17
Comment 10 Fedora Update System 2012-04-21 23:48:13 EDT
Package at-3.1.13-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing at-3.1.13-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6420/at-3.1.13-6.fc16
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2012-04-26 16:07:15 EDT
at-3.1.13-8.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2012-05-10 10:24:13 EDT
at-3.1.13-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.