Repository navigation
Replies: 3 comments 9 replies
|
Hi @MrQwerky, thank you for this thoughtful post and love & support as well. We do need to add some solid documentation around the options and usage of WinNUT. I guess the reasons for that not happening yet have just been other priorities as well as plans for larger changes to WinNUT that might outdate documentation anyways. But I'm always happy to answer questions and will probably learn more about how WinNUT works myself.
The information about the UPS shown on the main window is only supposed to reflect the state of the UPS and has no relation to the Shutdown options, only the Calibration tab for adjusting gauge settings. Same goes for the status indicators - NUT has a series of flags it uses to represent the state of a UPS device, so we show those in a graphical form. The shutdown conditions are only evaluated during a data update cycle in WinNUT, and only if the UPS is indicating an "on battery" status (see here if you want to browse the code for that.) When the UPS indicates it's on battery, then WinNUT updates the status indicators and goes on to check if both the battery charge and runtime variables are valid. If both are invalid, WinNUT logs an error and skips this part. But if at least one variable is valid, then it checks if a shutdown has already been initiated. If not, then WinNUT checks each variable to again make sure it's valid, then if it's below or equal to the condition set in the Shutdown menu, the shutdown process/window is launched (configured in the below options.)
I think you've got the gist of it. In addition to the condition evaluation algorithm I described above that triggers a "Shutdown_Event" as it's known in WinNUT, the shutdown procedure is actually also triggered when the UPS has indicated a Full Shut Down event as well. The Shutdown_Event process will check if the Immediate stop action is enabled, and if so, run the stop action. Otherwise, it activates the Shutdown_Gui which, while showing a nice GUI of the shutdown procedure, also doubles as the code that controls it. At this point, a timer counting the "Delay to Shutdown" option begins. If it expires, then the shutdown action from before is run. If the user enabled the Allow Extended Shutdown Time option, then they can click the button which should add the Grace Delay option to the current shutdown time.
Right, that will be the smaller window from before which shows the countdown time and offers the user a way to extend it.
Exactly, so it will follow the same process as if one of the other shutdown conditions had passed.
The NUT server was designed with this in mind: NUT has the concept of "logging in", which to it is in part authentication, but also indicating to the NUT server that this device is depending on it for power. When a Full Shut Down is triggered, or devices are following other conditions, then they log out from the NUT server to indicate that they are going down. NUT also has a capability to tell the UPS to shut off, which also has the side effect of power cycling devices like the Synologies which may be in their safe mode and waiting for a power cycle to boot back up. I've never managed to get it that sophisticated before though, and I'm not even sure if we have the capability to configure the Synology NUT software in that way, since it's the one ultimately controlling the UPS.
This is exactly how I have my client configured. I set the Shutdown if battery lower than ___ % value to about 95 or 100, so that the shutdown timer begins almost immediately once the UPS is on battery. I still give it about 10 or 15 seconds to give a chance for the power to come back on, but if not, then I want my server shutting down ASAP so this configuration works well for me. I acknowledge it could be a bit cleaner and more straightforward though, so stay tuned and please submit any ideas if you have a vision for how that'd look or work. I'm thinking I'd like some kind of generalized events system (see #92 for more discussion) so the user can configure how WinNUT responds to a variety of different conditions and parameters, with many different kinds of actions.
I want to mention here that there can be some confusion about what a low battery is. I believe there's a specific NUT UPS flag to indicate that the UPS is in some kind of low-battery state (as determined by some combination of the UPS's firmware programming, and perhaps a NUT configuration.) But WinNUT is also free to determine what a low battery is based on user input, although that doesn't affect the status indicators on the main screen which might've prompted your first question. But how you determine what a low battery is and means is an important question. I think it does depend a lot on your priorities. I personally want to take my machine (the WinNUT client) down sooner than later, so there's some battery power left over to run networking equipment. The Synology safe mode one has been difficult for me, because as far as I can tell the only way to bring it back out of safe mode is by powering the device off. This is fine and well for an extended power outage, but if the power comes back before the UPS shuts down, then the Syno can't be taken out of safe mode besides a complete power off. If you have some kind of Wake on LAN/MagicPacket client, it makes it easier to wake up devices that have shutdown so going down sooner rather than later may be ok. This does raise a need for some kind of low-powered, permanent device that go up or down without issue, and can monitor the UPS to orchestrate device power depending on conditions. |
|
Hello @gbakeman, thank you for the detailed response, which was very helpful. A suggestion, that any forthcoming documentation should include screenshots, as prior to your reply, I really didn't know how WinNUT would notify the user of a shutdown condition. It is very helpful to know that the user specified shutdown conditions are evaluated only when the UPS is on battery. My suggestion would be to add a third condition (in addition to battery level and remaining runtime), which would be a user-specified amount of time. This, if enabled, would begin counting down as soon as the UPS indicates "on battery", and upon reaching zero, would initiate the shutdown procedure just as is done now for the other two conditions. It seems to me that the work-around of having a very high battery level (95% - 100%) as a shutdown criteria, together with a timed delay, would be workable for the initial power-fail/shutdown. However, in the case of an extended power outage, when the power is eventually restored, the UPS battery may be at some very low level (certainly much lower than the specified 95% - 100% level), and it may take considerable time for the battery to once again reach full charge. In such a case, if a second event should occur after the client is rebooted, but before the battery is fully charged, the client would once again immediately initial the shutdown procedure. Perhaps that might be a desired condition, or not. But with having a timeout criteria as well, the battery level criteria could be used for its intended purpose of watching for a (perhaps very) low battery condition, rather than being repurposed to act as a timer. Yes, I believe your analysis that the Synology "low battery" condition is based not on a particular level, but on a signal from the UPS, is entirely correct. The Synology does have a setting to restart after a power failure, but I suspect that this would take effect only after the NAS is shut down, and not when it is in safe mode. The NAS does also have a wake-on-lan capability, but I've never been able to get it to work. I suspect that the WOL feature only works when the NAS is in safe mode, and not when shut down, but haven't confirmed this as I'm not sure how to have the NAS enter safe mode apart from the low battery setting. If that were confirmed, then the solution would be to enable the restart feature for when the UPS shuts down, and use the WOL feature when it does not, and the NAS remains in safe mode. Interestingly, it seems that Synology NASes have an issue with the FSD signal latching, so WinNUT's ability to ignore that signal is very important. |
No argument from me on that. I think before I get carried away on the big events system idea, it would be good to make a few smaller tweaks to how WinNUT configures and responds to power conditions first. I would definitely do this one.
I want to double check my understanding of your thoughts in this part by proposing an implementation: Let's say we're maintaining the original initial triggers of either an On Battery or Full Shut Down flag (per user config) from the UPS. But when either of these things happen, we'll begin the following "Shutdown" procedure. If the user indicates a wait timer, then that will begin counting down. Maybe we'll keep the grace timer option too. If the user indicates battery level and/or runtime conditions and either of those are evaluated true, then the timer is bypassed. When any of the conditions (timer, battery level, % charge) have expired/become true, the chosen shutdown method is executed right away. This way, a timer can be used if the user prefers, but otherwise the battery indicators are treated as urgent conditions. Is that about what you're thinking?
I just went to take a look at my own Synology config to recall. Apparently when WoL is enabled, then it also enabled the Restart automatically when power supply issue is fixed option. I don't recall it starting up on its own, nor have I ever been able to coax it out of safe mode when the grid power comes back before the battery runs out. I think it will respond to pings, but nothing else. I think I also remember it leaving the drives spun up while it was in safe mode, which is no good for UPS battery life. Only option is to hold the power button to shut it down, so safe mode has been a pain point of mine. Ideally, I'd get the events system for WinNUT done so one could launch a shell session with the DiskStation and tell it to shut down completely. Then, In my own experience, the DiskStation is able to do WoL about 99% of the time when it's in a powered off state. There was one time where the power had come back from total shutdown but the network interface didn't make a link for some reason. Otherwise, it's been very dependable this way. My router (opnSense) has a nice UI for sending WoL packets to devices on the network, so it's a convenient if manual way to manage my devices. Still not giving up on that low-powered orchestration device idea though.
That's another interesting point. I believe the NUT server is meant to latch on FSD so it needs to go down and back up to reset. I took a peak at your next reply and think I see you talking more about FSD so I'll submit this now and move on. |
|
Hi, @gbakeman. I need to check my understanding of how it works now: when "on battery" occurs, WinNUT then begins monitoring the user-specified battery level and remaining runtime, but not before "on battery". When either of those criteria meet the specified level, then the shutdown procedure occurs, which begins by notifying the user and initiating the delay timer. When that timer expires, the shutdown action is taken, unless the user activates the grace delay, which extends the time by that amount before finally taking the shutdown action. Now, when FSD is asserted (and is enabled), then the action that is taken is identical to that taken when battery level or runtime criteria are met, i.e. notifying the user and beginning the delay countdown. Is this correct, or, does FSD bypass the delay timer and immediately shut down? What I had envisioned in my earlier reply, was to have a timer option right above/below the two current options of battery level and runtime. This would operated exactly like the other two, and would be a user-specified amount of time until the shutdown procedure is initiated, and would begin counting down when "on battery" occurs. So, when any of the three criteria are met, the shutdown procedure is initiated, exactly the way it is now, with notifying the user and beginning the delay timer. I would also keep the grace timer in place, as that is a user-initiated action. My thought was that this "on battery" timer (or whatever you would like to call it), would have an enable checkbox, like is done now for FSD. However, on second thought, the enable checkbox might be redundant, as the default could simply be a very large value, so that it would never expire unless the user set it to a lower level. So, the delay timer (and grace timer) would take effect whenever any of the above three conditions was met (remembering that the delay timer [and grace timer] only begin counting when the shutdown procedure is initiated, which begins after one of the conditions is met). For example, the on-battery timer might be set to 15-30 seconds, to allow for brief power interruptions, while at the same time quickly notifying the user when a more lengthy outage occurs. Then, the delay timer might be set to three to five minutes, allowing the user time to save and close applications. If the user chooses not to use the on-battery timer, it can remain set at a high value, and so the battery level or runtime conditions may trigger the shutdown action. In this case the user would probably have the delay timer set to a short time, as there would already be significant time before battery level or runtime conditions trigger. Now, on to the Synology NAS. Full disclosure: I'm using two Synology NASes, but both are rather old (one from 2018, and one from 2010), so the DSM on each is also rather old. After beginning this discussion, I did a fair bit of searching for information on the Synology NUT server, but what I found may not be completely relevant to my own systems. It seems that on some (newer?) versions, the FSD signal latches, but does not clear when the NAS comes out of safe mode, and may require the user to log in to DSM and stop/start the NUT server. But according to my testing done yesterday (see my other post further down), when the NAS came back up, the FSD signal was not latched (which is a good thing). But also, according to my testing, when in safe mode, I could no longer access data on the drives, but nevertheless the drive LEDs were still lit; so I can't really say whether or not the drives were spun down. Also, while in safe mode, I was still receiving responses to ups.status queries (done outside of WinNUT), but really don't know whether they were actual current conditions, or just the last know condition. However, the NAS definitely did restart (from safe mode) when the mains power was restored. So the differences between our two experiences with Synology NASes may well be accounted for by different ages of the NAS/DSM. All of which is to say, that WinNUT can't be (and shouldn't be) responsible for the NUT server. |
What you had described there sounds exactly right.
I think I understand completely now - I had over-complicated your thoughts previously, even though you were quite clear that the user should be able to have a separate timer option to the battery level and runtime options, just like we were talking about before. Very straightforward and should be fairly easy to implement.
I think I liked your idea of having a checkbox, just so it's clear to the user that they can enable or disable this timer option and it'll remain independent of the other battery properties to launch a Shutdown timer.
Good examples given here. I feel I'm on the same page as you.
That's some interesting research you've conducted here. Thank you for sharing that, and I'll look for your additional reply below. |
|
Agree, I do think we are pretty much on the same page, and I look forward to some of these things being implemented, so I don't really have much to add at this point, but will continue to monitor this thread! Interestingly, I had an actual 50 minute power failure last Tuesday, but it occurred at night, after I was already in bed, so all of the desktops were shut down. With only the NAS and network gear consuming power, the UPS was easily able to keep the NAS up, which again did go into safe mode, and did restart when power was restored. Just a bit more data on the Synology, but of course doesn't really have anything to do with WinNUT. |
|
Some further thoughts. What does WinNUT do should the server go down, and WinNUT loose connection. Does it initiate the shutdown sequence? One suggestion might be to provide a "lost connection" countdown timer, just like the others. Some results from my testing: Synology NAS set to enable WOL; with Synology, this also forces enabling of restart on power return. Synology NUT server set to enter safe mode after 20 seconds. WinNUT client configured to shutdown when battery level is below 100%, with delay set to five minutes to provide time for testing. Then I pulled the UPS power plug. The Synology immediately indicated "on battery". The WinNUT client also immediately indicated "on battery", and the "on-line" indicator changed from green to yellow. The client immediately initiated the shutdown sequence without waiting for the battery level to fall to 99%, thus indicating that the WinNUT client "Shutdown if battery lower than" setting is really "Shutdown if battery is lower than or equal to". The client also immediately showed the ups.status as "FSD OB DISCHRG", so the Synology asserts FSD immediately. Is this correct procedure according to NUT specifications? Next, the Synology appeared to enter safe mode, as the "STATUS" LED turned off, although the drive LEDs remained on, and the "LAN" LED continued to blink with activity. At this point, repeated queries from the client continued to indicate the same ups.status of "FSD OB DISCHRG", so I'm not sure whether the NAS NUT server was simply repeating the last condition each time it was queried, or whether it was still responding with the current condition. I did receive an e-mail from the NAS saying that all services are shut down. But in either case it was still actually responding to queries from the client machine (outside of WinNUT). Restoring power caused the NAS to initiate a reboot, and immediately caused the WinNUT client to terminate the shutdown sequence. There was no opportunity to send the NAS a WOL signal, but it did confirm that the Synology can indeed restart when power is restored, at least from safe mode; I did not let the battery drain completely so as to cause the NAS to loose power. It is interesting to me that at power loss, WinNUT showed the "on battery" indicator as green, but changed the "on-line" indicator from green to yellow, rather than either changing it to red, or simply turning it off. Does this indicate that the UPS was no longer on mains power, but that the NUT server was still on-line; and that had the NUT server gone off-line, the indicator would have changed to red, or simply turned off? This is another situation where documentation would be very helpful. |
Very good point. As far as I know, WinNUT does not have any kind of fail safe mechanism if the NUT server goes down before the UPS goes on battery. I'm not even sure what would happen if the NUT server goes away while WinNUT is in the middle of it's shutdown procedure, because I think WinNUT is still regularly querying the NUT server. So if the NUT server goes away, then I think WinNUT would have no choice but to disconnect and reset its self into the disconnected state. I have no idea what happens to the shutdown procedure GUI in that case. Definitely a case that needs testing and most likely work. Having a fail safe mechanism like you suggested, with a timer that starts when the server goes away, is probably the only/best option. I also want to have WinNUT talk to UPSs that are connected locally, at least to interact with the Windows Battery API to get basic information of whether the local machine is on line power or battery.
OK, good you confirmed that.
Good observation, I'll need to follow up on that.
Hmm... I thought there was another discussion or issue here regarding Synologies and FSD flags, but I can't seem to find it. I recall having problems with the Synology keeping the FSD latched as you mentioned and needing some form of reset or another. I did manage to find this blog post and this reddit post about it, but no real answers as to why the DSM software behaves this way. Not normal operation to answer your question!
Did you happen to notice if it spun the drives down, by any chance?
That's good you can maintain a connection to it.
That's amazing. I need to experiment more with safe mode myself now.
Also a very good question and point. From my quick searching, it looks like the only colors of that indicator are green, yellow and white (not connected.) But it is a bit of an odd way to communicate and definitely needs documentation. Are you thinking we may use this indicator for your previous suggestion of handling a NUT server connection loss? I'd also want to leave this indicator as one for the OL flag/UPS specifically, although I also want to handle server connection losses better so something needs to change. I want to give you some time to respond to my posts and offer any more thoughts you may have, and then collect this conversation into some actionable points to add to issues for implementation further down the line. Thanks again for your thoughtful engagement. |
|
My thoughts above about the colour of the status indicators was more of a question, as I didn't really know whether WinNUT presently considers connection loss. If you think it best to keep the indicators as they are, that is completely fine. Another option would be to add a "connection" indicator, although at the risk of making the main window either larger or more crowded. But adding a connection-loss timer in the settings does seem to be a good idea. I wonder whether the NUT documentation has anything to say about this? I think I have responded to the rest in my recent post above. |
|
Since you mention it, I do want to indicate server connection a little better in the GUI, and you've also made the excellent point that a downed server needs better handling in WinNUT. |
|
Hi guys, I'm watching this with great interest as I'm a bit of a newby to NUT. I used to run APCUPSD on my Windows server which worked fine but when I changed my rather small APC to a large Liebert UPS I assumed that APCUPSD would no longer work. It turns out that actually it probably would have with some tweaking but now I'm quiet deep into learning NUT and linux. I have just tested the scenario of the NUT server (running OpenMediaVault BTW) being offline and what WinNUT Client will do. The result is that it actually locks up as it is continuously trying to re-establish connection. Whilst this is not really a problem there is a scenario where it could be. If for some reason the Linux box is offline and there is a power cut the Windows box will never shutdown. If it is a planned outage of the Linux box such as a reboot then it's up to me to manage it. If it's a system failure then it would be nice to be able to set a "lost communication timer" on WinNut client which then initiates a shutdown. If I was using NUT-Client there are apparently settings in upsmon.conf that would achieve this. Anyway I am digressing somewhat from the origional point of this conversation |
|
Hi @DickyDoDah, welcome to the project and thanks for posting here. I'm glad you found this discussion, and it sounds like you have an important concern that's shared here. I was just looking through the upsmon documentation too since you mentioned it, and it is interesting how they handle different situations and it's probably worth using this as a guide. Something that's confusing to me is I'm aware that a UPS can have a "stale" flag represented by the NUT server, which I believe means that the NUT server wasn't able to poll the UPS in the expected timeframe. upsmon also uses the stale terminology, but it seems like that's independent of what the NUT server says about the UPS, and more about how upsmon is communicating to the server like we would be in WinNUT. Regardless, thank you for adding your thoughts here and please do continue digressing. It's clear to me that we need to handle an unreachable NUT server in WinNUT better than is now currently. I'll be back to digest this topic and our thoughts into issues to move this forward. |
Uh oh!
There was an error while loading. Please reload this page.
First of all, many thanks for your hard work in continuing to support this project for such a period of time.
So, I've spent considerable time searching both this repo and the web in general, for information regarding proper configuration of WinNUT-Client, and what the settings actually do, without much success. Perhaps if I posed some specific questions, specifically with regard to the Shutdown Options?
Firstly, how do those options relate to the status shown on the main window? Do the shutdown options take effect even when the UPS is On-Line, or only when it is On-Battery?
When a shutdown condition occurs (low battery, low runtime), what procedure does the program follow? My best guess would be that once the condition occurs, the Delay to Shutdown time is allowed to elapse, and then if the Extended Shutdown Time is enabled, that the Grace Delay time is also allowed to elapse, and finally the program initiates a Windows shutdown (or according to the Type of Stop selection).
When such a condition triggers this procedure, does the program notify the user in any way?
What is the procedure when an FSD condition occurs (and is enabled); does it go through the same time delays as above, and also notify the user?
Finally, I would appreciate some best-practices recommendations as to configuring the WinNUT-Client and the NUT server to operate together. For example, it would seem to be imperative that the computer shut down before the server does. The server (in my case, a Synology NAS) may be configured to enter safe mode either after a specified time, or when the UPS battery level becomes low.
If set for a specified time, it must be long enough to allow the client computer to react and shut down, whether the client is configured to wait for specified low battery level, or low runtime, and including the shutdown timeouts; but not so long that the UPS is depleted before the server can enter safe mode. This configuration would be greatly helped if WinNUT-Client had an option to shut down after a specified time without regard to battery level or runtime remaining.
Or would it be better to configure the server to enter safe mode when it reaches a low battery state, and configure WinNUT-Client to shut down when the battery reaches some low level which is higher than the level targeted by the server? This is complicated by the fact that I have no idea what that target level in the server is, as it simply says "Until low battery".
Looking forward to some helpful information.
All reactions