Working Around RTC Limitations
To conserve energy at work I configured three non essential computers to power down nightly. I scheduled a morning wake up using the real time clock (RTC). Two of the systems are used for testing changes before rolling out the same changes to production systems. One of the test systems ran Proxmox 5 (Debian 9), the other ran CentOS 7. The third system was a nominally used Ubuntu MATE 16.04 desktop.
These three systems are not used on weekends. I wanted the systems to stay powered off for the weekend and awaken Monday morning rather than the next day.
I had some shell scripts I wrote years ago for my home network. I updated the scripts to support the extended conditions desired for the work systems. Everything worked as expected except for the Proxmox system.
That stubborn computer is a Dell PowerEdge 2950 rack server used for testing. An old rack server, but only used for testing. Every Monday the computer refused to awaken.
Being a test system there was no urgency to resolve the failure, Yet after several weekends of this behavior I tired of manually booting the system with a wake-on-lan magic packet. I decided to dig deeper.
Eventually I discovered the Dell’s RTC only supports wake up times up to 24 hours in the future. I had never seen that limitation. My home systems support one month or one year. Of the two other work systems I had configured for this shutdown schedule, one supported one month and the other one year. Hence no issues with awakening Monday mornings.
I now knew why the system failed to awaken on Monday morning. Setting the RTC wake up time was failing. I added an error handler and some log spew support. After adding the support I then noticed a kernel log message about the RTC limitation in the middle of my newly added log spew.
rtc_cmos 00:01: Alarms can be up to one day in the future
I checked one of the Dell R710 servers at work. Same RTC shortcoming, although those systems run 24/7.
I understand that rack servers are designed with a presumption of running 24/7. Hence wake up times are unlikely to be a priority. Still, why use a limited chip set like this? What is saved? Perhaps newer Dells do not have this limitation — I don’t know.
I could live with the Dell not shutting down for the entire weekend but that missed the original goal.
There was no way to overcome the RTC limitations. I let the script “fail” when the wake up time exceeded 24 hours in the future. The script still performed the shutdown, but with no valid wake up time, the system would not awaken itself Monday morning. On another server on the same subnet in the same building I created a cron job to send a wake-on-lan magic packet Monday morning.
I hate kludges.
Posted: Category: Usability Tagged: General
Next: A Newbie Installing VirtualBox
Previous: Firefox 57 — 2