fix: address ulimit exhaustion of user within swag-proxies.py

[wandercone]

Proxies table briefly loads then disappears on full page load. This will dynamically assign max_workers based on resource.RLIMIT_NPROC

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description:

Make /dashboard/swag-proxies.py dynamically assign its worker count based on the current process/thread limit:

• Added import resource.
• Added get_max_workers(default=50, reserve=10):
  • Queries resource.RLIMIT_NPROC.
  • Caps workers at min(default, max_procs - reserve).
  • Falls back to default if the limit cannot be read.
• Replaced the hardcoded max_workers=100 with max_workers=get_max_workers().

On the reported container (ulimit -u = 100) the script now uses min(50, 90) = 50 workers, leaving headroom for interpreter threads and avoiding the RuntimeError.

Benefits of this PR and context:

proxies.php executes /dashboard/swag-proxies.py without the fast flag. That script created a ThreadPoolExecutor(max_workers=100). When a ulimit nproc of soft/hard of 100 is specified within compose this causes the hard coded max_workers of 100 to exceed the limits.

RuntimeError: can't start new thread

The Python traceback was written to stdout, so PHP’s json_decode() received invalid JSON and returned null. proxies.php then iterated over null, producing an empty and the PHP warning:

PHP Warning: foreach() argument must be of type array|object, null given in /dashboard/www/proxies.php on line 18

Because the AJAX call replaces the whole table on success, the initially rendered rows were overwritten with an empty table.

How Has This Been Tested?

Loaded in browser and SWAG instance with 21 proxies loads as expected now with ulimits: nproc: soft: 100 and hard: 100.

Source / References:

n/a

[LinuxServer-CI]

PR build pushed to ghcr.io/linuxserver/mods:pull_request_1156

[quietsy]

LGTM
Thanks for the contribution