I am trying to run command “ulimit -n” & pasting its output to a text file on Linux Servers, its running fine but that output which its creating is not matching at all with user created file or system entries.
ulimit -n referring the ulimit entries in file /etc/security/limits.conf which is -
-
hard nofile 8040
-
soft nofile 8040
When I am running ulimit -n with root privilege using my ID manually on linux box its generating output of “8040” but whenever I am running it from Bigfix its generating output “1024”
So just want to check if anyone experiencing or experienced same scenario or was able to understand why this is happening ?
Below are the methods which I used to run it with different ways but no luck.
*Appendfile
*Creatfile
*Sh script directly
And more interesting, even when I am running bigfix created appendfile/creatfile shell script manually that creating output of 8040
Greetings.
I’ve tested in my environment and am able to get the correct ulimit output through BigFix via shell script and actionscript. Can you paste an example of the code you are using?
-Matt
ohhh thats bit strange are you using v9.5.11 ?
Below is the action script from which I am trying to pass the results.
//delete older files
delete __appendfile
delete /tmp/ulimitout.txt
delete /tmp/limitstatus.sh
//passing output of current ulimit numbers
appendfile #!/bin/bash
appendfile ulimit -n >> /tmp/ulimitout.txt
move __appendfile /tmp/limitstatus.sh
wait chmod 777 /tmp/limitstatus.sh
wait chmod +x /tmp/limitstatus.sh
wait /bin/sh /tmp/limitstatus.sh
Using the code you provided, I am still able to get the correct ulimit output. The only difference in environments is that mine is running the newest 9.5.13 agent. I would maybe double-check the limits.conf configuration.
-Matt
OK ! Can you please post your limits.conf file for ulimit entry & besclient action results.
I hope its very much similar to as are mine which is mentioned below.
OK was able to find issue but thats not a solution after deleting __BESData folder its showing exact command results.
We are facing this problem on all linux/unix machine and deleting BESData folder is not a feasible solution at all.
I guess I need to raise PMR.
You haven’t mentioned which Linux distribution you are using; it’s entirely possible your variant overrides limits.conf. Have a look at http://landoflinux.com/linux_ulimit_command.html , particularly the notes around /etc/security/limits.d/90-nproc.conf
Also, note the differences between a shell launched by Bigfix is not a login shell (by default); so if you are raising soft limits by, for example, one of your shell dot-files like .bashrc that won’t be reflected in the command launched by Bigfix, unless you launch with something like
wait /bin/bash -l -c "ulimit -n > /tmp/ulimit.out"
See https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html for notes about login shell v/s non-login shell.
2 Likes
Jason makes a very good point here. I was testing this against the CentOS boxes in my environment. So far in testing against SuSE and Debian, I am getting the behavior where the output is 1024 and not what is set in ‘limits.conf’.
-Matt
Jason, I am trying fetch info from RHEL machines & its not that I am changing anything, its just I am trying to generate the output of hard/soft ulimit using command ulimit -n but its not giving the exact value which is there in /etc/security/limits.conf
Thanks for it, I will try it, if its solve the problem 
Ohhh Thank God I am not alone 
Yes, now we have same question how to get the exact results.
Red Hat makes use of the /etc/security/limits.d directory. Is there anything in that directory? If so, what is the content?
If it’s Red Hat 7, I believe some of the limits that apply to besclient itself may be different due to the use of systemd. There are probably better references than this but have a look at https://unix.stackexchange.com/questions/345595/how-to-set-ulimits-on-service-with-systemd
Don’t get too excited yet. 
The distribution that I had the same output as you was SuSE. On RHEL 7.5 the output is what I have set in limits.conf (8040).
Doing a little more investigation to get to the bottom of this.
@JasonWalker
I am not setting any ulimit with my task as of now, there is another task which copy limits.conf & update it with new ulimit entries for hard/soft 8040, which is perfectly working fine.
What I am trying to achieve is, until unless server is not rebooted after changing limits.conf file those changes would not last, hence I am using ulimit -n to fetch the output into a file just to make sure server is already rebooted & having latest value in that particular task for updating limits.conf so that it dont get applicable again.
This folder only contains - 20-nproc.conf
But I am not able to understand, what makes changes in system that after deleting __BESData folder I am getting exact 8040 output when running command ulimit -n from bigfix,which was earlier 1024.
What is in the 20-nproc file?
Ok I misunderstood your previous message, I thought Bigfix was still reporting 1024 after deleting BESData.
Have you tried restarting the besclient service? Rebooting the machine without deleting BESData?
yes ! I have restarted it multiple time coz without reboot ulimit settings are not persistent.
Also while troubleshooting with fixlet,I thought there could be issue with client so removed BESData folder & after it started reflecting ulimit values.
But deleting BESData folder across all server would not be possible & feasible solution ! hence still looking for some other alternatives.