Pushing Nut on Windows....

[aarnold-sd68]

I thought I'd see how far I could push NUT on windows, and it seems I may have hit the limit. I'm getting this message : EventLog : upsd - upsd polling 64 filedescriptors, but wanted to poll 66 and was constrained by maxconn=64. But I can't seem to find any information on how to fix this, as the documentation states it's set to the max of the operating system. It seems to load up until mv-appc1500core and then the web servers gets a 502 error, and "Error while connecting to NUT server localhost, disconnect" after that it seems to get upscli_try connect: connection to host timed out: '::1'. I'm assuming I'm hitting some upper limit here of what the Windows version can do. Any thoughts on how I can work around this or is it just not possible?

MONITOR MAINUPS@localhost 0 admin 1Pass4UPS primary
MONITOR DRUPS@localhost 0 admin 1Pass4UPS primary
MONITOR APCIS8@localhost 0 admin 1Pass4UPS primary
MONITOR ND-Vertiv-UPS3000@localhost 0 admin 1Pass4UPS primary
MONITOR JB-Vertiv-UPS3000@localhost 0 admin 1Pass4UPS primary
MONITOR DV-Vertiv-UPS3000@localhost 0 admin 1Pass4UPS primary
MONITOR WE-Vertiv-UPS3000@localhost 0 admin 1Pass4UPS primary
MONITOR JB-APC3000-Server@localhost 0 admin 1Pass4UPS primary
MONITOR JB-APC3000-Core@localhost 0 admin 1Pass4UPS primary
MONITOR PA-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR BR-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR BV-APC1500Core@localhost 0 admin 1Pass4UPS primary
#MONITOR CA-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR CB-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR CR-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR CT-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR DB-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR DC-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR FN-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR FP-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR FV-APC1500Core@localhost 0 admin 1Pass4UPS primary
#MONITOR GB-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR GE-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR HB-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR IC-APC1500Core@localhost 0 admin 1Pass4UPS primary
#MONITOR LI-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR LP-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR MG-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR MV-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR CE-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR NO-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR PH-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR PV-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR QW-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR RR-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR RC-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR RF-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR SV-APC1500Core@localhost 0 admin 1Pass4UPS primary
MONITOR UP-APC1500Core@localhost 0 admin 1Pass4UPS primary

[jimklimov]

Thanks! Docs do mention a MAXCONN setting that the log also alluded to, see https://networkupstools.org/docs/man/upsd.conf.html

But on Windows, its API limits this to MAXIMUM_WAIT_OBJECTS (defined as 64) per https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects which suggests some ways around it too:

To wait on more than MAXIMUM_WAIT_OBJECTS handles, use one of the following methods:

• Create a thread to wait on MAXIMUM_WAIT_OBJECTS handles, then wait on that thread plus the other handles. Use this technique to break the handles into groups of MAXIMUM_WAIT_OBJECTS.
• Call RegisterWaitForSingleObject or SetThreadpoolWait to wait on each handle. The thread pool waits efficiently on the handles and assigns a worker thread after the object is signaled or the time-out interval expires.

So essentially we could look at waiting for first N sockets, then next N sockets, and so on. Might even use offsets in the same array of file descriptors (or Windows HANDLE's) to do so. It might add up the delays (sum of wait timeouts, arbitrarily 2 sec here, if no socket has new data buffered), unless we also multi-thread the blocks of waits and somehow safely collate the results.

When I began writing this, I thought it would be a big change and so something better delayed until after finally cutting a NUT release - or it would remain "just behind that corner". But at least without threading, it might in fact be a simple change. Maybe still better merge it after a release, but at least you would have something to test :D

[jimklimov]

Posted a PR. Without threading and legacy behavior by default (so should be working same way for deployments that run okay now), it seems in fact low-risk enough to merge in this release cycle, so timely testing would be much appreciated.

[aarnold-sd68]

I followed the link from the PR you created, but unfortunately it looks like there is an issue with compiling :(.

https://ci.appveyor.com/project/nut-travis/nut/builds/53498830/artifacts <--Is the link I followed.

[aarnold-sd68]

Looks like it's now creating artifacts, still showing red. I'm assuming that means that I should run this in production, or if I do with caution :).