Setting "ulimit" is Not Working and Throwing Errors
Solaris / OpenSolarisThis forum is for the discussion of Solaris, OpenSolaris, OpenIndiana, and illumos.
General Sun, SunOS and Sparc related questions also go here. Any Solaris fork or distribution is welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Setting "ulimit" is Not Working and Throwing Errors
Hi,
In order to increase "ulimit" I followed this article as it explains the same error that I receive while doing that on OpenSolaris (my local test box) as well as on Solaris 10 (production box):
bash-3.2# mdb
> maxuprc
mdb: failed to dereference symbol: unknown symbol name
> pidmax
mdb: failed to dereference symbol: unknown symbol name
>
Code:
bash-3.2# ulimit -u
8021
bash-3.2# ulimit -u 30000
bash: ulimit: max user processes: cannot modify limit: Invalid argument
bash-3.2#
Any help?
Side Note:At this point I am not concerned about the ulimit's ideal size or any philosophy behind it. I just need to do that on a production box per the instruction / requirement we have received. But as stated above, it is not working.
That is because you are missing to set pidmax (and other tunables) properly. The article you cite tells to set them in the /etc/system file and then reboot for the kernel to get them, not to use the unrelated shell set command.
The article you cite tells to set them in the /etc/system file and then reboot for the kernel to get them, not to use the unrelated shell set command.
Not sure, then, why the "set" commands are shown in the article. However, changing "/etc/system" will make system wide changes- for all users. We want to do it for specific users. Besides, a reboot would be required. It's a production box which is not supposed to be rebooted without a change request/control.
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,789
Rep:
Quote:
Originally Posted by devUnix
Not sure, then, why the "set" commands are shown in the article.
Because that's the correct syntax. Why do you think there is a problem with these "set" commands ?
Quote:
However, changing "/etc/system" will make system wide changes- for all users.
Indeed and the article is quite clear these settings are system wide. Three of them do not make sense "per user" anyway.
Quote:
We want to do it for specific users.
Then you might want to investigate resource controls, especially max-lwps.
Quote:
Besides, a reboot would be required. It's a production box which is not supposed to be rebooted without a change request/control.
If you need to raise tunable values than cannot be set dynamically, there is no other way outside rebooting. However, some of these variables looks like to be changeable online using kmdb, although it is always risky doing it on a production system.
By the the way, you missed to pass the correct option to mdb (mdb -k), that's the reason why your mdb commands failed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.