Many thanks to those that responded to my original posting with information about Network UPS Tools and commercial UPS products.
In our planning a path forward to implement UPS-based power fail protection, we have come across what appears to be an issue with the state of the CentOS 6 machines being UPS protected. Most of these machines are desktop/deskside machines that are likely to be idle during non-work hours. It is also likely that they will be hibernating or in a power save mode.
In the power save mode, these machines do not respond to keyboard or mouse activity. They also do not respond to network traffic such as a ping from other systems on the network. The method we use to wake them up is a quick push on the power button when the hibernation state is indicated by the button's yellow LED display.
This state of hibernation leaves us wondering if these systems will be able to respond to network messages sent by the UPS. We have not yet made it all the way through the NUT and UPS documentation. The hibernation answer may very well be therein, but we have not found it so far. Any help or direction regarding the hibernation issue as it relates to UPS power fail protection will be appreciated.
Thanks again and best regards.
On Wed, Aug 16, 2017 at 8:49 AM, Chris Olson chris_e_olson@yahoo.com wrote:
Many thanks to those that responded to my original posting with information about Network UPS Tools and commercial UPS products.
In our planning a path forward to implement UPS-based power fail protection, we have come across what appears to be an issue with the state of the CentOS 6 machines being UPS protected. Most of these machines are desktop/deskside machines that are likely to be idle during non-work hours. It is also likely that they will be hibernating or in a power save mode.
In the power save mode, these machines do not respond to keyboard or mouse activity. They also do not respond to network traffic such as a ping from other systems on the network. The method we use to wake them up is a quick push on the power button when the hibernation state is indicated by the button's yellow LED display.
This state of hibernation leaves us wondering if these systems will be able to respond to network messages sent by the UPS. We have not yet made it all the way through the NUT and UPS documentation. The hibernation answer may very well be therein, but we have not found it so far. Any help or direction regarding the hibernation issue as it relates to UPS power fail protection will be appreciated.
Suspend to RAM and suspend to disk both sync filesystems before the system suspends, so what should be true is the file system is consistent. The log might be dirty, but this would be replayed at next boot if there's a power failure.
The only thing that would be lost is any unsaved work. The old school answer is, save your files before you sleep the computer; i.e. the burden is on the user.
My position is, this is a solved problem on mobile, where apps take responsibility for saving state including user data. Some do this locally, some sync it to the cloud. So far I'm not seeing this become much of a thing on the desktop, other than macOS where it's fairly standard at this point. Libreoffice by default saves autorecovery information every 10 minutes, for example.
On 8/16/2017 7:49 AM, Chris Olson wrote:
Many thanks to those that responded to my original posting with information about Network UPS Tools and commercial UPS products.
In our planning a path forward to implement UPS-based power fail protection, we have come across what appears to be an issue with the state of the CentOS 6 machines being UPS protected. Most of these machines are desktop/deskside machines that are likely to be idle during non-work hours. It is also likely that they will be hibernating or in a power save mode.
In the power save mode, these machines do not respond to keyboard or mouse activity. They also do not respond to network traffic such as a ping from other systems on the network. The method we use to wake them up is a quick push on the power button when the hibernation state is indicated by the button's yellow LED display.
This state of hibernation leaves us wondering if these systems will be able to respond to network messages sent by the UPS. We have not yet made it all the way through the NUT and UPS documentation. The hibernation answer may very well be therein, but we have not found it so far. Any help or direction regarding the hibernation issue as it relates to UPS power fail protection will be appreciated.
in general, there's two power save states, 'Standby' aka 'Sleep', where the system state is held in RAM, but the CPU and peripherals is shut down and sleeping, and "Hibernate" where the ram is saved to disk and the system is completely powered down.
In sleep, if the power is lost, then you'll need to reboot when the power comes back up. The system is using very little power, so your UPS should last much longer.
In hibernate, you can restore when the power returns. Hibernate, however, takes a few more seconds to wakeup, so people often use Sleep as it wakes up relatively instantly.
In neither of these states will the system be able to listen to ANY network traffic, as the processor is simply not running. The one exception is Wake-On-Lan aka WoL. You probably COULD configure a master always-on NUT box to send WoL to a list of such systems, wait a suitable amount of time for them to come back to their senses, then send them Hibernate commands via NUT.
Utilizing WoL requires configuration on the target hardware to recognize and accept the WoL, this is typically done at the BIOS level, and only works if the system supports WoL in the first place. WoL commands can typically only be sent over the same local network segment, as they are layer 2 packets sent to the MAC address of the target.
On 08/16/2017 02:31 PM, John R Pierce wrote:
in general, there's two power save states, 'Standby' aka 'Sleep', where the system state is held in RAM, but the CPU and peripherals is shut down and sleeping, and "Hibernate" where the ram is saved to disk and the system is completely powered down.
That's what I thought too, until I read "man rtcwake" and discovered there are five standby modes. A major problem-solver in this context would be some code added to that to allow a network connection to communicate with a UPS or server. Given that Wake-on-LAN wouldn't be necessary.
In sleep, if the power is lost, then you'll need to reboot when the power comes back up. The system is using very little power, so your UPS should last much longer.
In hibernate, you can restore when the power returns. Hibernate, however, takes a few more seconds to wakeup, so people often use Sleep as it wakes up relatively instantly.
In neither of these states will the system be able to listen to ANY network traffic, as the processor is simply not running. The one exception is Wake-On-Lan aka WoL. You probably COULD configure a master always-on NUT box to send WoL to a list of such systems, wait a suitable amount of time for them to come back to their senses, then send them Hibernate commands via NUT.
Utilizing WoL requires configuration on the target hardware to recognize and accept the WoL, this is typically done at the BIOS level, and only works if the system supports WoL in the first place. WoL commands can typically only be sent over the same local network segment, as they are layer 2 packets sent to the MAC address of the target.
-
Chris Murphy -
Chris Olson -
John R Pierce -
ken