Instant sleep after wake
DarylKrans opened this issue · 5 comments
This is not incredibly important as I've managed a work-around, at least for myself. I'm also not sure if the bug I'm reporting is one of the current existing bugs already open.
I've noticed this issue in the few different versions I've tried where after autopoweroff meets its requirements to suspend the system, the system is then suspended. However, upon waking the system, it instantly goes back to sleep and I have to wake the system at minimum 3 times before the system will stay running (even with dependent IP's being up).
I have made a work around in bash. It's had limited testing but seems to be working so far. Instead of having autopoweroff suspend the system itself, I have it run a bash script which first gets the PID for autopoweroffd, then issues a 'service autopoweroff stop' command. The script then issues a 'kill' command to autopoweroffd and waits to see that the process was fully terminated before issuing a command to suspend the system. I wrote another script that is run upon resuming the system that starts the autopoweroff service again.
This seems to have alleviated the undesired suspend after wake. It will need more testing.
I don't know if this is actually a bug in autopoweroff itself or a bug presented by the configuration of my system. I've tested and concluded the issue is only present if autopoweroffd is still running at the time of suspend.
As inconvenient as the issue was, I had a lot of fun tracking it down and scripting a fix (band-aid) for it!
Suspend-script.txt
StartAPO-script.txt
When you power up the computer, is it in the [StartHour, EndHour] range defined in /etc/autopoweroff/autopoweroff.conf? Because that is what you want. The computer must wake up in the range of time Autopoweroff is not allowed to run the command. It makes sense that if, upon wakeup, all the conditions are again met, that the computer goes to sleep immediately, again. I use Autopoweroff myself (latest version) and I do not have this problem.
# StartHour and EndHour parameters (expressed in hours):
#
# Following is the time range where the computer should not take any action
# even if all conditions are met. In this example where StartHour=5 and
# EndHour=22, the computer will not take action between 05:00 and
# 22:00, local time.
[NO_ACTION_TIME_RANGE]
StartHour=5
EndHour=22
Ah yes, there are also these two parameters you should consider:
# StartupDelay parameter (expressed in minutes):
#
# When the computer is booting up, if all the conditions are met and the
# computer is in the action time range, as soon as Autopoweroff is started,
# the computer will take action. Thus, the user will never have the chance
# to boot into the computer. This is where the "delay" parameter comes in.
# If "delay" is set to 15 for example, Autopoweroff will not poweroff the
# computer even if all the conditions are met, for a period of 15 minutes
# after the computer has booted. This allows the user to login and change
# Autopoweroff's configuration.
#
#
# IdleTime parameter (expressed in minutes):
#
# Like a screensaver, Autopoweroff detects keyboard and mouse activity, and
# if there is any activity on the server, it would not be powered off
# regardless if all the other conditions are met. If set to 0, user
# activity on the server will be ignored.
[TIMEOUTS]
StartupDelay=5
IdleTime=2
I had the same problem it appeared after the deployment of 4.1.2. but since 4.2.0 it's gone. And as the release was shortly after I deployed 4.1.2. I didn't investigated it any further.
StartupDelay and IdleTime were set as in the example.
Yes, I confirmed I fixed it in commit ff57c44d1ccda7ab1770b668529fdb776f976150, which made it into 4.2.0 as @it-jonas stated (thanks Jonas).
I fixed it because myself, during testing, suffered of the same problem. Now you have 2 minutes to kill Autopoweroff after the first time it ran the command, if Autopoweroff starts misbehaving.