0

I am using Solaris 11 and it is my understanding that a non-privileged user can increase or decrease the soft limit of maximum open file descriptors while staying within the hard limit. It is also possible for a non-privileged user to decrease the hard limit but it cannot increase the hard limit once it is decreased.

I am experiencing the following scenario. I have a non-privileged user whose soft and hard limits are set as following using the ulimit command.

Soft limit: 10000

Hard limit: 10000

-bash-4.4$ ulimit -n
10000
-bash-4.4$ ulimit -Hn
10000
-bash-4.4$ ulimit -Sn
10000

That means the user shouldn't be able to launch any process with a limit of maximum open file descriptors higher than 10000. But I am unable to explain some processes which are running as the same user with a higher open file descriptors limit. I have several such processes running.

-bash-4.4$ plimit 12553
12553:  
   resource              current         maximum
  time(seconds)         unlimited       unlimited
  file(blocks)          unlimited       unlimited
  data(kbytes)          unlimited       unlimited
  stack(kbytes)         8192            unlimited
  coredump(blocks)      unlimited       unlimited
  nofiles(descriptors)  65536           65536
  vmemory(kbytes)       unlimited       unlimited

It is a java process and is running in a Solaris Zone. The parent process is zsched. All the information provided is from within the zone. The process command is shown below as well.

java -d64 -DAppName=java_app -server -Xms2048m -Xmx6144m -Xmn2040m -

I do not have much information regarding the process itself and how it got launched. Is there any particular scenario that I am missing which can allow this non-privileged user to use a higher open file descriptors limit?

My Assumptions:

This information might help. On the machine under question, the limit is being set in the file /etc/profile using the following command:

ulimit -n 10000

That means, the file is called every time the user logs in and the limit is applied. It is my assumption that it might be possible that such processes are not being launched using the normal interactive login or even a non-login shell. The /etc/profile is called in both an interactive login and interactive non-login shell (as per my observation); so a process launched from that shell shouldn't have a higher file descriptor limit.

It could be due to a non-interactive shell like scripts or cron which doesn't need to call /etc/profile and thus might use some other default limit. But looking at these processes, this scenario seems to be unlikely. Are there any other possibilities?

Although we have support for Solaris, the community isn't really much helpful; so we are relying on these forums for any help.

Improve this question
10
  • "It could be due to a non-interactive shell like scripts or cron which doesn't need to call /etc/profile ... this scenario seems to be unlikely" -- What makes you think this is unlikely? This is exactly what happens.
    – phemmer
    Dec 26, 2017 at 15:09
  • 1
    You might want to try using resource management to do this.
    – Mark Plotnick
    Dec 26, 2017 at 19:19
  • As far as the Solaris community on MOS, it's very similar to this type of forum. Only difference is that community is more likely to have a Solaris engineer make a comment. And I don't think you have to have a support contract to be a member of that community. And if you have support, you could always open a case.
    – sleepyweasel
    Dec 26, 2017 at 20:26
  • @MarkPlotnick I have already looked into projects. I tried to make a project and assign the user to the project with a higher files limit. The limit in /etc/profile simply overrides that setting whenever the user logs in. Is there any other way this scenario could occur? Could here be a default project involved or something? How to verify?
    – Alchemist
    Dec 27, 2017 at 5:15
  • @Patrick Like I mentioned, I don't have much information about the processes. I can confirm though that it is not a cron. Not sure about the scripts. They just didn't seem like a cron or scripted processes. I will try to get more information on that matter and share any findings.
    – Alchemist
    Dec 27, 2017 at 5:18

1 Answer 1

Reset to default
1

Not sure I completely follow what you're asking.

Odds are a SA added the ulimit entries into /etc/profile for a COTS product (usually database) or custom app.

The reason you're seeing a different value via plimit could be that the user/app could have set a different value, or it could be being picked up by another resource control mechanism. ie: /etc/project

Improve this answer
1
  • The part about ulimit being in /etc/profile was just information. The question was that how do those processes have a higher files limit than that already. As far as I know, it is not possible for a non-privileged user to raise the limit higher than the hard limit. I have already looked into projects. I tried to make a project and assign the user to the project with a higher files limit. The limit in /etc/profile simply overrides that setting whenever the user logs in. Is there any other way this scenario could occur? Could here be a default project involved or something? How to verify?
    – Alchemist
    Dec 27, 2017 at 5:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .