It is possible after a very long period for the server to stop functioning, requiring a restart.
Problem:
There is a slow handle leak in exacqd introduced in server version 9.5.25/9.6.0. This handle is never used, so a slow memory leak is the result.
Windows has a limit of 16 million handles. A server that leaks 3 handles a minute would take 4 years to hit this limit. A server with many LDAP users always connected would hit this limit sooner.
Solution:
Current workaround is to downgrade to 9.4. Future versions should include fix.
CyberProtection requirement that software not run with elevated privileges by default.
Change
Traditionally, one process runs when the exacqVision Server Service starts: ‘core’ (Linux) or ‘core.exe’ (Windows). Beginning in 9.6, tasks that require activating a binary or script will be moving (over time) to the new ‘exacqd’ (Linux) or ‘exacqd.exe’ (Windows) process. This includes executables packaged with the Server installer, as well as OS-level programs.
The following binaries will be executed by exacqd in 9.6 (others will move in upcoming releases):
On Service start, the exacqd process will start first, which will then start core. Additionally, exacqd will restart core if it crashes. These two processes will communicate with each other through a protected pipe (IPC). The user experience should be exactly the same after upgrading.
One improvement due to this change is that the exacqVision Server start/stop is now significantly faster.
Eventually, the ‘core’ process will be able to run without elevated privileges. In problem scenarios, ‘exacqd’ will be able to restart ‘core’, but ‘core’ cannot restart ‘exacqd’. While unlikely, if the ‘exacqd’ process dies, the Server logs will show:
exacqd ipc pipe disconnected sleeping for one minute to allow active watchdogs to expire...