The output is :

fs.file-nr = 1664 0 3265265

Sorry, i did not understand the link you are giving me !!

this may not work ( since you need root, and too many files may be 'open' already )

what isthe output?

The output of /sbin/sysctl fs.file-nr as root is :

root@server2 [~]# /sbin/sysctl fs.file-nr
fs.file-nr = 1760 0 3265265



root@server2 [~]# sudo lsof -u 0 2>/dev/null | wc -l
1736


thank you for wanting to help me

that looks reasonable, but I don't know what loads you have.

can users do "sudo -i" ?

I suspect your max openfiles per user is 4096, root currently has 1736
if you have a number of root shells open, you could end up hitting that 4096 limit, thus the shell won't open ( no resources )


if you experience problems 'more often than not' , then look at

/etc/security/limits.conf
/etc/security/limits.d/

along with
man limits.conf

with a view to raising the limits

oh,

and I would ask myself why these guys all need root shells

No, the users can't run sudo -i, but if i run this command, the error message changes, in this case the error message is : enable to execute /bin/bash, not /bin/su

was that recently, or from before?

what is the output of
what kind of services are running?
how many users?

Is this new/sudden? yes ... what changed recently? ... new service / network mount / users


you are hitting some resource limit, need to figure out which

From before



As user is :

core file size (blocks, -c) 200000
data seg size (kbytes, -d) 200000
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256637
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 200000
open files (-n) 100
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 35
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited


As root :

core file size (blocks, -c) 1000000
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256637
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14335
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

ok, do you know the UID of the user?

nevermind..
as root

The output is :

root@mserver2 [~]# lsof -u $(id -u adminet) | wc -l
151


the UID is : 32013


sorry I made you tired .

ok

go back to

see if increasing the "nofile" limits helps

or look at the openfiles, and close some ( if you can )

Your "max user processes" and "open files" look really really low:

Compare yours above to mine below. I am running a standard install of LinuxMint, what you see below are the defaults:
And sitting here, running no user processes on my computer other than the Xfce desktop, the Firefox browser I am typing in right now, and a single terminal window, I am already running 46 processes. Even that is above your limit of 35:
I believe your extremely low settings for user open files and max processes is what is killing you. Why do you have these parameters set so low? IMHO, these settings are so low as to be almost unuseable.

I guess it is a multiuser system , many users logging in remotely


someone spent some time setting the limits up


I guess adminet is a special case, as I don't know why everyone should be able to get root

the limits.conf manpage should help with setting appropriate limits for adminet

I think they should spend a bit more time reviewing the limits they came up with then.

35 processes is extremely low, even for commandline only users with no GUI, unless those users do basically nothing but sit there and stare at their command prompt. I could live with an open file limit of 100 however, assuming these users are not running production processes, servers, etc.

It is good to set user limits on a production system. It is bad to set those limits unrealistically low.

Anyway, the issue here is not good or bad practice by sysadmins. It is the failure to invoke sudo for this specific userid. No doubt that is because of the low user max process limit, as evidenced by "Resource temporarily unavailable".

O.P. - Get the sysadmin to up your user max process limit and I'll bet that error goes away. Alternately, kill some of the processes you are currently running to make room for more. You will need to kill more than one of your excess processes, because "sudo su -" will try to start up a handful of processes, not just one.

again, I'm guessing ...

my guess is the server is providing ssh accounts, which often have low limits but suitable for irc and the like.

the questions are

is this new behaviour for adminet?
i.e. were they able to "sudo su -" ( or sudo -i ) in the past or is this a new requirement.

depending on the answer..
what changed?
or..
What do we need to change?