-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smarter/Quieter/Indefinite Reconnection attempts #65
Comments
Indefinite is a must. |
Hello. My nas is the UPS master and it auto powers off during night until 9 am to preserver HDD lifespam. |
I'm definitely thinking that, at minimum, we have an option (by default) where WinNUT will just indefinitely attempt to make a re-connection to the NUT server if it was previously connected successfully (connection lost event) without any kind of notification. The last item in the log would be a notification that ongoing connection attempts are occurring. How important is scheduling to you? Perhaps we can just do a simple ping instead if you want lower overhead. |
No, schedules are not a must, but as you said indefinitely attempts would bee great. |
In my opinion this kind of software should be always connected, and if there is no connection for any reason, keep reconnecting all the time. Maybe the time between tries should be dynamic rather than a fixed interval, but it should be able to reconnect no matter what. This kind of software should be designed to work unattended to work as expected. |
I vote for the Quieter part of this issue. My WinNUT client connects to a rpi which hosts the UPS. While the rpi is performing backups (about 1 hr) most services are stopped including NUT services. I have to exit WinNUT before the rpi backup and restart WinNUT after the rpi backup is done and NUT services are available again. It would be great if a single "Not Connected" and a single "Connected" notification appeared an hour later. |
I've been running this for a week with no issues. awesome work |
@kirsch33 Thanks for the extended test! I'll probably have a pre-release by next week. |
Tried v2.3.8981 while backing up the rpi (nut server) as described in my comment above. It is almost perfect now. Nice work! On Win10 I got a single notification when the nut server stopped. "Reconnection In Progress\nReconnection..." When I look at the recent messages drop down list in WinNUT Client there are three messages.
|
Hey @yoyoma2 thanks for the feedback on this. I've tried artificially disabling my network adapter and re-enabling it a couple of times to simulate the network (or server) going down, and I'm able to see WinNUT display the "Connected" notification when it reconnects. Can you confirm that it's not sitting in your notification drawer? If that isn't the case, could you please upload a debug log where you reproduce this scenario? |
I backed up the rpi (which stops the NUT server for an hour) with Debug level log enabled in the WinNUT client. The whole time WinNUT client was closed to systray. Here's are the notifications: Description of log:
Here is the log. The connection being reestablished is somehow not being reported even though it is happening. |
Thank you for your detailed work on this. That's very interesting since it looks like WinNUT logging a connected event and even preparing the NotifyIcon (the icon that sits in the Windows taskbar), but the toast just doesn't seem to be triggering. I've created a new issue in #182 so let's continue conversation over there. I've also created a debug build, please repeat the test just as you did now. Thank you for your efforts here! |
It would be useful if WinNUT could attempt to reconnect to the NUT server indefinitely. This would mean that it is quieter about the reconnection attempts. If the tools are available, then it may also be useful if WinNUT can first detect if it's even possible to make a connection first (network adapter is up & route to the NUT server is available), otherwise wait until the conditions are present.
Ref #63
@f33d13ack
The text was updated successfully, but these errors were encountered: