To solve #2396 I've tried to do what appears to be the smaller change, move the NPROC rlimit change from an XrdScheduler constructor to a dedicated method, which is only called from the server code. A Scheduler object is still constructed as part of the XrdUtils.so library and in the case of client that will be unused. However rearranging the set of global objects in the 'XrdGlobal' namespace (used by some Xrd/ classes, e.g. XrdLink XrdPoll) seemed to be a larger change.

I've just relised Andy's comment:

Additionally, certain client plugins rely on the NPROC limit to be changed even in the presence of XRD_WORKERTHREADS setting.

is of course relating to clients and this patch could does change that case. I'll make another revision.

@smithdh Could you please base your branch on master? That will avoid the CI failures on Alpine and macOS. Thanks!

Revised & rebased to master:

The intended behavior this patch should bring now:

(i) By default keep same behavior for servers (i.e. things which construct an XrdConfig object, cmsd & xrootd daemons). That means the nproc soft rlimit is set to 30000 if possible.

(ii) Other things that link or load libXrdUtils.so have a modified behavior: instread of setting the limit to 30000, the limit is raised to 30000 unless it is already less restrictive than that. (i.e. this applies to apps like xrdcp, frm_xfragent etc but could apply to anything linked with XrdCl, including python bindings or c++).

(iii) Introduced XRDLEAVENPROC: If that env variable is set then NPROC is not changed (in either of the cases).

@smithdh This is ready for merging, right?

Yes, this is ready to merge. Thanks.