I am using Nxlog 5.4.7313 and I have such a config block. <Input perf_process> Module im_exec BufferSize 200 Command "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" Arg "-ExecutionPolicy" Arg "remotesigned" Arg "-File" Arg "C:\scripts\Get-ProcessUtilization.ps1" Restart TRUE </Input> <Output out> Module om_file File 'c:\nxlog.txt' </Output> <Route client> Path perf_process => out </Route> When the service starts, it doesn't write anything to the output file. But if I execute "stop-process -name powershell" as administrator, then the next cycle will restart powershell scripts and the data will appear in the output. Also, the command "net stop nxlog" cannot independently stop the scripts that were launched for the first time.

There is a bug in NXLog Community Edition 2.10.2150, with module im_ssl regarding opening CA files. NXLog seems to create a file descriptor for the CA file each time a new connection is made. That is, NXLog opens the file again and again. If NXLog runs on Linux, this can quickly hit the OS limit of maximum number of files open. The following error is seen repeatedly once the OS limit of file descriptors is reached: ERROR SSL error, failed to load ca cert from '<path_to_file>', Too many open files Raising the OS limit is only a temporary solution: eventually, the next limit can be hit How can this bug be fixed?

Hello, We're testing nxlog and at least a few times per day it's throwing this error. When this happens the error repeats itself in the logs for a few hours until either the log fills up the  partition or the kernel kills nxlog due to memory running out (Out of memory: Kill process 2422 (nxlog) score 762 or sacrifice child). I'm not a C programmer but looking at the om_dbi driver source it seems to me as if this assertion might be checking if the length of the SQL query is longer than a predefined constant. Could this be the case? Is there a limit on the size of the SQL query nxlog can send? I think I might be wrong because I've hardcoded SQL queries I believe are longer than those triggering the assertion error and they went through just fine. I came across a thread on the same error and the poster stated they resolved the issue by recompiling nxlog from source. I did that but unfortunately the latest available source is from an older version and couldn't get our nxlog.conf to work with it. Any ideas what this assertion is checking? BTW, NXLog is running on CentOS 6.8 and there's plenty of free memory (8 GB) and CPU power available. Thank you, Babak B.