After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793766 - Suspend on idle not working again after wake-up for sheduled task
Suspend on idle not working again after wake-up for sheduled task
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-02-23 18:07 UTC by Zener131
Modified: 2021-06-14 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Zener131 2018-02-23 18:07:19 UTC
* cinnamon-screensaver v.3.2.13+serena
 * Distribution: Mint 18.1-xfce-64bit on Shuttle XS35V5 Pro (Intel HD Graphics)
 * same issue on:
 * Distribution: Mint 18.2-cinnamon-64bit on PC Asus Prime B250 Pro (internal video)
 
**very short summary**

The suspend-on-idle works fine with a real User, but not with automated nightly processes, probably due to the assumption I found in the code (notice at the end).

**context**

1) The sleep mode is changed to 'hibernate' (the issue shows better but is present with 'suspend' too).

2) Settings are done to lock the screen after 15mn idle (screensaver "XMatrix") then in power management:  'never' turn off the screen then sleep after 1h.

3) The BIOS is set to allow waking up the PC with both mouse, keyboard and RTC event.

4) I use 'rtcwake' and 'cron' to schedule wake-ups for nightly backup tasks (on account 'root' of course).

5) All works fine in normal use case: 
a) the PC hibernates after 1 hour idle as expected, 
b) moving the mouse wakes it up: Grub's menu with delayed default boot then I end on the login screen,
c) nightly backups operate well and they end properly with no big job or undue connection remaining...
=> So basically there is no problem in the normal "user mode" use case.

**Issue**

After such a nightly backup, the PC does not hibernate again. Hours after it is still showing the screensaver active.
If in this state, I just move a bit the mouse and do nothing else, then after the expected 1 hour delay, the PC hibernates again.
What looks to mean that the suspend-on-idle cycle is not rearmed after first completion, when the PC wakes-up, unless real user activity occurs again.

**Steps to reproduce**

Enable wake on mouse move, keyboard and RTC event in the BIOS.
Setup to lock screen after 15mn idle, never turn off then suspend after 1h.
Change mode to hibernation:
sudo gsettings set org.cinnamon.settings-daemon.plugins.power sleep-inactive-ac-type 'hibernate'
Schedule a wake-up past this time (care, this uses UTC time):
sudo rtcwake -m no -u -t $(date -u --date="<when>" +'%s')
Let the PC hibernate and wait, don't touch anything more.
Once confirmed the issue, you can move the mouse, nothing else, not even login again, then wait for the hibernation delay to confirm it works fine when there was any user activity after a wake-up.

**Expected behavior**

The PC should go back to hibernation when it has been idle (no user activity) for the wanted delay, even if there was no user activity since the last wake-up. 

NB: The solution of explicitly requiring a sleep at the end of a given scheduled task, should it work from a cron task with no GUI session, could not be taken as acceptable.
The reason is that it would do it regardless of other potential running tasks.
The PC must go to hibernation when it is idle, that is: no user activity, in a system-wide consideration.

**Other information**

Of course I tried to neutralize the backup task itself and anything I do to prevent the sleep during the backup, with no effect on the issue. These parts are innocent.

I tried to fake some user activity (moving the mouse with utility 'xdotool') as part of the scheduled task but it changes nothing. Probably does it nothing since it runs on 'root' with no interaction with the suspended user's X session, I guess... But the methods borrowing the user's X session lead to corrupt it in strange ways (password requested for anything after, including for hibernation, so no gain).

So I don't think such DIY methods could lead to a clean and natural behavior matching what "suspend on idle" must mean for the multitude. This behavior must be built-in.

**my finding in the code of gnome-session**

I noticed this assumption that visibly matches the issue:
https://github.com/GNOME/gnome-session/blob/master/gnome-session/gsm-presence.c#L188
=> Wrong imho when the PC wakes by itself with no GUI interaction.
Expert point of view needed there: what is the exact meaning of "not-idle" there ? both PC and user or at least the PC ? 
Maybe should rather the event "unfreezing on wake-up" be considered too...

Thank you, Best regards.
Comment 1 André Klapper 2021-06-14 18:21:32 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of gnome-session, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.