The number of open files is displayed incorrectly

[evgeny-test]

Please complete the following tasks.

• Web browser cache cleared
• Link provided to install script if applicable
• Not using broken rtinst install script
• Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

FireFox 153.0, PHP 8.5, Debian 13.6, rTorrent 0.16.18, ruTorrent 5.3.11

Tell us how you installed ruTorrent

I just downloaded the release from GitHub and unpacked it.

Describe the bug

The number of open files in the status bar is always 128.

When I change the setting for the maximum number of open files, it is not saved when I click OK.

Then I set "network.max_open_files.set = 512" in the settings file, but it didn't show up in ruTorrent after restarting rTorrent.

Steps to reproduce

No response

Expected behavior

No response

Additional context

No response

[xirvik]

Proper fix requires some patch to rtorrent (I submitted it, hopefully it will be merged for 0.16.19), but for now try

ulimit -n 16384

Before starting rtorrent.

network.max_open_files is ignored now in rtorrent. It uses the process limit so you need to increase it externally.

[xirvik]

@evgeny-test Can you test #3145

On rtorrent 0.16.19+ - previous versions won't work.

Let me know if this works for you.

[evgeny-test]

Hi. I tried installing rTorrent 0.16.19 and ruTorrent from fix/max-open-files-settings branch.
Now the status bar values ​​change, and the number of open files remains around 128.
Changes to the settings aren't saved and always show 128.

[xirvik]

Hi. I tried installing rTorrent 0.16.19 and ruTorrent from fix/max-open-files-settings branch. Now the status bar values ​​change, and the number of open files remains around 128. Changes to the settings aren't saved and always show 128.

Two things to check:

1. What file-descriptor limit is the running rtorrent actually under? From a shell:

   pgrep -af 'bin/rtorrent'
   grep 'Max open files' /proc/<pid>/limits
   

   (note pgrep -x rtorrent finds nothing — the process name is rtorrent-main.)

The first number is the soft limit, and it is exactly the budget the socket manager divides up. If it still says 1024, the new limit never reached the process: ulimit -n only affects things started from that same shell, so if rtorrent runs under systemd or a supervisor it needs LimitNOFILE=16384 in the unit (or the equivalent) and a restart.

2. With the limit still at 1024, try setting 256 rather than 512. If 256 sticks and 512 does not, the patch is working and the fd budget is the constraint.

In any case, obviously the "silent reject" is super annoying. I've updated the PR. Give it another try please.