fivem icon indicating copy to clipboard operation
fivem copied to clipboard

LOAD_RESOURCE_FILE not closing file handles

Open Nimplex opened this issue 1 year ago • 3 comments

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

  1. Open many file descriptors
  2. Watch FXServer slowly die

Importancy

Crash

Area(s)

FXServer

Specific version(s)

Server 7290 windows

Additional information

No response

Nimplex avatar Mar 08 '24 23:03 Nimplex

Does the same occurs when using the functions provided by the ScRT and properly closing them?

local file = io.open()
--  ...
const file = fs.readFileSync()
// ...

Yum1x avatar Mar 09 '24 03:03 Yum1x

I don't know, I've never tried using io.open()

Nimplex avatar Mar 09 '24 10:03 Nimplex

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.

tens0rfl0w avatar Mar 10 '24 15:03 tens0rfl0w

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).

Nimplex avatar Mar 10 '24 16:03 Nimplex

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.

tens0rfl0w avatar Mar 10 '24 17:03 tens0rfl0w

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.

Nimplex avatar Mar 10 '24 18:03 Nimplex