Can not raise ulimit when running a command like ubuntu2004 run "ulimit -n"

[István Ujj-Mészáros (istvan-ujjmeszaros)]

I have edited all the files that were mentioned in other related threads, but nothing seems to affect the limit when using ubuntu2004 run "command". ubuntu2004 run "ulimit -n" is always returning 1024 and I couldn't find any workaround to raise that. Is there a way to do it? The goal would be to have a higher limit with the above command (using WSL v2).

[therealkenc]

$ mylimit=8000
$ sudo prlimit --nofile=$mylimit --pid $$; ulimit -n $mylimit

[therealkenc]

Below works for me, although for the record, I don't like it....

Probably, in the very narrowest sense, the correct solution is fix zsh. Which is probably not as hard as it sounds. That original "value exceeds hard limit" error is incorrect; the value does not exceed the hard limit. [Unless someone has an otherwise compelling rationale that the error is correct.]

Another solution perhaps is to just not bother telling zsh that the limit has been updated with prlimit. Any child of zsh is going to inherit the new limit, whether the parent zsh knows it has a higher limit (as reported by the zsh ulimit builtin) or not. Ie, just skip the exec, and let the ulimit output be wrong.

More broadly, doing init and 'loginthings asrootin.bashrc/.zshrc(or.dotfile) is an imperfect hack in the first instance. Big hammer solution is probably to march down the #994 rabbit hole, and do the prlimit` before the user shell is entered.

And lastly, but not leastly, it looks like the default NOFILE hard limit might have been quietly raised to 1048576 somewhere along the way. I can't actually confirm or deny that change, but (shell builtin) ulimit -Sn 65536 just kind of takes without special treatment, at least as of 21390, anyway. Which from a practical standpoint probably makes the problem mostly moot once the default increase change rolls in a release build.

[Markus Osanger (mosanger)]

therealkenc nice, thank you! it left me with a shell that wasn't loading any plugins or settings though.
adding this before anything else in my .zshrc fixed that issue:

ULIMIT=65536
if [[ "$(ulimit -n)" != $ULIMIT ]]; then
    sudo prlimit --nofile=$ULIMIT:$ULIMIT --pid $$
    exec /bin/zsh
fi

source "${HOME}/.zgenom/zgenom.zsh"
# rest of your .zshrc
# ...

[JSamir]

For me, using zsh4humans, solution from Markus Osanger (@mosanger) has worked.

[Sebastian Iorga (sebastianiorga)]

I don't understand why the related issue as closed. It's really not an acceptable solution to have a sudo command in .zshrc. Is the idea that this is a zsh specific bug not a WSL2 bug?

Changing /etc/systemd/user.conf and /etc/systemd/system.conf and then su USER_NAME seems to produce the right ulimit.

The value exceeds hard limit issue might be caused by the system.conf setting. I added DefaultLimitNOFILE=102400:524288 in there and DefaultLimitNOFILE=65535 to user.conf. Then I added ulimit -n 65534 to .zshrc and it seems to work fine when opening new tabs.

[kanjieater]

I did everything Sebastian Iorga (@sebastianiorga) mentioned, but it still didn't work. Needless to say other solutions hadn't either.

Seems this was the only thing that worked for me
Clear any other modifications of /etc/security/limits.conf and recreate the file like this:
sudo nano /etc/security/limits.conf

root    -   nproc   500000
root    -   nofile  500000
myuser  -   nproc   130000
myuser  -   nofile  130000

[therealkenc]

In .bashrc or .profile, potentially, with sudoers on prlimit(1).