LOAD_RESOURCE_FILE not closing file handles
What happened?
On the server I have a script that relies on a large number of open files, I noticed that after some time reading and writing files, the server stopped writing and reading files, many scripts began to return errors, specifically: "Listening on socket failed - libuv error EMFILE, "[ net-tcp-server] error on connection: too many open files". In the code responsible for the "SAVE_RESOURCE_FILE" and "LOAD_RESOURCE_FILE" functions, I did not notice the logic responsible for closing the file descriptor.
Expected result
Server should automatically close file descriptors when file operations end
Reproduction steps
- Open many file descriptors
- Watch FXServer slowly die
Importancy
Crash
Area(s)
FXServer
Specific version(s)
Server 7290 windows
Additional information
No response
Does the same occurs when using the functions provided by the ScRT and properly closing them?
local file = io.open()
-- ...
const file = fs.readFileSync()
// ...
I don't know, I've never tried using io.open()
The file stream is correctly closed when the objects lifetime ends (after exiting the scope of the SAVE_/LOAD_RESOURCE_FILE native functions and removal of the streams ref).
Also, testing this with random reads and writes to over 30k(!) different resource files showed no exhausted stream I/O file descriptor limit (which sits at 512) and no increase in open file handles, so this normally works quite well.
You may have to provide a repro here.
I am not sure how to reproduce this error, it happens sporadically. I managed to reduce the frequency of its occurrence when I changed the logic responsible for writing logs (some even have several thousand lines in one file).
Well, there has to be some more info, otherwise how should anyone be able to even find a direction where to look at. Are you accessing the resource files from within multiple resources, concurrent threads, ...? Any info like that could probably help.
I would like to correct in advance the version of the server I am using, we are using version 7290 on linux (ubuntu 22.04 minimal). It reads files from multiple resources at the same time, the error occurred when with each new chat message I read the contents of the log and saved it by adding new logs to the end of the file. Most of the write and read operations are done in new threads.