| Summary: | Interval schedules: save backup asap after missed schedule time | ||
|---|---|---|---|
| Product: | [Applications] kup | Reporter: | kde |
| Component: | general | Assignee: | Simon Persson <simon.persson> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 0.9.1 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/system/kup/commit/e09c9b1e9fcdc34d157c383694dee5e00cf091e3 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
kde
2023-02-08 21:11:00 UTC
Thanks for the report! Very clear. I will need to look into how the process sleep is handled across suspension, I think I had tested that and it worked back long ago when I worked on that part of kup. Thank you for your kind reply. Just for the record, I cannot with certainty say that the issue is linked to putting the device in sleep mode. I never keep it running > 24h, so I don't know if the backup would be triggered correctly w/o the interim sleep condition. I am not a Linux expert, but if there is any test I can run or log I can retrieve to help you, please let me know. So, I am a bit confused. I tried reproducing the issue more conveniently by setting the backup interval to 5 minutes. Observations: 1) If the system is suspended and then immediately woken up again before the 5 minutes are over, it resumes the backups as scheduled. 2) If the system misses a backup while asleep, it will not perform a backup after waking up to compensate. But it will resume when the next 5-minute-interval is reached. So I think what is missing is that I would expect a backup to be performed after system resume, if the previous backup has been missed. OK, excellent. Then it actually behaves as designed then. I agree that saving a new backup as soon as possible after a missed schedule would be good to have, and users would be right to expect it. For anyone who has time and interest to help fix this problem: The current scheduler goes to sleep with a duration which is the remaining time until next "backup save time". The solution here could be to instead just sleep 5 minutes and then upon wake up, check if it's time to save a new backup. If not, go back to sleep for another five minutes. Apologies, I still believe I fully haven't understood what is actually going on. I put the interval back on 1 day, and unlike when I had the 5-min-setting, it did not execute the backup when the 24 h were exceeded despite the PC being powered on at the time (although it had been suspended in the interim). So something still isn't quite right I guess? That said, kup realizes that something is amiss - the icon turned yellow when the 24 h were exceeded. Git commit e09c9b1e9fcdc34d157c383694dee5e00cf091e3 by Simon Persson. Committed on 22/02/2023 at 21:25. Pushed by persson into branch 'master'. Change sleep duration for interval plan executor The problem was that time spent with computer in suspend mode was not advancing the process timer. So backup saving every 24 h would happen 27 hours after last save if three hours was spent suspended. Fix by checking if it's time to save every five minutes. M +4 -2 daemon/planexecutor.cpp https://invent.kde.org/system/kup/commit/e09c9b1e9fcdc34d157c383694dee5e00cf091e3 |