[colug-432] ulimit

Rick Hornsby richardjhornsby at gmail.com
Sat Jan 14 16:50:24 EST 2012 



On Jan 14, 2012, at 15:33 , Jon Miller wrote:

> Does your /etc/Pam.d/su file use Pam_limits?

Yes, I think it does indirectly.

there is a line in /etc/pam.d/su:

    session include system-auth

in /etc/pam.d/system-auth is

   session required pam_limits.so

I added "debug" to the end of that line and ran a couple of su commands, but didn't see anything in /var/log/messages


-rick





> - Jon Miller
> 
> On Jan 14, 2012 4:31 PM, "Rick Hornsby" <richardjhornsby at gmail.com> wrote:
> 
> Unfortunately, this has come up again.  I thought we were right setting the ulimit in /etc/security/limits.conf, but when I looked at the actual tomcat process which was started from an init script which contains this line:
> 
> su - tomcat $TOMCAT_INSTANCE/bin/startup.sh
> 
> The FD limit is maybe getting inherited from the shell which started it - root's.  The value for root is the system default of 1024, but 8192 for the tomcat user in /etc/security/limits.conf.
> 
> I also tested this by kicking off tail using sudo (su terminated with a '&' acts the same)
> 
> sudo -bu tomcat tail -f /var/log/dmesg > /dev/null
> 
> When I check the limit in /proc/PID/limits, it is 1024 not 8192.  If instead of doing sudo right away, I do
> 
> ulimit -n someval; sudo -bu tomcat …
> 
> then the tail process, owned by tomcat, gets a limit of someval.
> 
> I really don't want to do a hack and have the init script read /etc/security/limits.conf for the tomcat user, change the value and start tomcat …
> 
> 
> any other thoughts?
> 
> thanks
> -rick
> 
> On Dec 19, 2011, at 17:38 , Jon Miller wrote:
> 
> > Yes Jeff, you are correct and have the best answer to the question. My
> > answer was the "cowboy" answer which really isn't expected to be
> > followed but merely interesting to mention what you can accomplish via
> > a kernel module hack. And as you've pointed out, you can update your
> > ulimit value, within your hard limit, from within the process itself.
> > In my scenario, I needed to alter a process I did not own and
> > furthermore update a value potentiall beyond it's hard limit. Again,
> > that was my cowboy solution.
> >
> > -- Jon Miller
> >
> > On Mon, Dec 19, 2011 at 4:17 PM, Jeff Frontz <jeff.frontz at gmail.com> wrote:
> >> Slight correction - you can change ulimit values on a running process on a
> >> stock 2.6 kernel, but only from inside the process (via a call to setrlimit)
> >> and only to decrease it in an unprivileged process.
> >>
> >>> From the FC7 setrlimit(2) man page:
> >>
> >>        The soft limit is the value that the kernel  enforces  for  the
> >>  corre-
> >>        sponding  resource.   The  hard  limit  acts  as a ceiling for the
> >> soft
> >>        limit: an unprivileged process may only set its soft limit to  a
> >>  value
> >>        in  the range from 0 up to the hard limit, and (irreversibly) lower
> >> its
> >>        hard  limit.   A  privileged  process  (under  Linux:  one   with
> >> the
> >>        CAP_SYS_RESOURCE capability) may make arbitrary changes to either
> >> limit
> >>        value.
> >>
> >> Jeff
> >>
> >>
> >> On Mon, Dec 19, 2011 at 4:05 PM, Jon Miller <jonebird at gmail.com> wrote:
> >>>
> >>> Correct, you're not supposed to be able to change a ulimit value of a
> >>> currently running process. That said, I've done it before via a custom
> >>> kernel module. I was actually originally interested in resetting a
> >>> signal handler for a currently running process in order to
> >>> successfully generate a corefile. In the process of testing, we found
> >>> out that the corefile I was getting was zero bytes because their
> >>> ulimit for corefile size was set to 0. So, I made another update to
> >>> the kernel module and was able to change the corefile size ulimit
> >>> value to unlimited on the fly too.
> >>>
> >>> All the while we had a case open with Novell & IBM and needless to
> >>> say, they didn't like the idea of me creating a kernel module but it
> >>> worked and we got the desired corefile finally. I have a short writeup
> >>> on the ordeal on my blog:
> >>>
> >>> http://jonebird.com/2007/06/21/stripping-another-process-of-its-signal-handler/
> >>>
> >>> -- Jon Miller
> >>>
> >>> On Mon, Dec 19, 2011 at 3:26 PM, Rick Hornsby <richardjhornsby at gmail.com>
> >>> wrote:
> >>>>
> >>>> On Fri, Dec 2, 2011 at 2:57 PM, Mark Aufdencamp <mark at aufdencamp.com>
> >>>> wrote:
> >>>>> A helpful link:
> >>>>>
> >>>>>
> >>>>> http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
> >>>>
> >>>> Thanks.  That was one of the things I read before posting that got me
> >>>> really turned around.  The language is very confusing, especially when
> >>>> he says things like "75000 files normal user can have open in single
> >>>> login session."  That makes it seem like it is almost a per-user
> >>>> (per-session more specifically) limit.
> >>>>
> >>>> Someone else said that the ulimit was a per-process restriction, and
> >>>> this appears to be true. /proc/<pid>/limits confirms this.
> >>>>
> >>>> Recompiling the kernel isn't an option, but it is good to know that
> >>>> this is where the default of 1024 comes from.  Based on what folks
> >>>> suggested here and additional research, /etc/security/limits.conf is
> >>>> the place to set it.  Something that took me a while to get is the
> >>>> soft/hard limits.  Unlike disk/printer quotas, these different limits
> >>>> do not refer to warnings or other information that lets the user know
> >>>> they're about to run out.  Rather, the hard limit is the
> >>>> kernel-enforced maximum.  The soft limit can be set by the user, up to
> >>>> the hard limit.  So maybe the hard limit is 1024, but they decide a
> >>>> process has run away if it hits 128 open FDs.  That would be a use for
> >>>> the soft limit.  I believe, like a pid's nice value, the user can
> >>>> lower their own hard limit (priority), but once lowered, they cannot
> >>>> raise it.
> >>>>
> >>>> It does not, however, appear that it is possible to change the ulimit
> >>>> of a currently running process.  When a process starts up, the
> >>>> kernel(?) figures out what limits it should have, and those last for
> >>>> the life of the pid.
> >>>>
> >>>> ulimit is just one of those things that seems to be poorly documented
> >>>> and not well understood.
> >>>>
> >>>> -rick
> >>>> _______________________________________________
> >>>> colug-432 mailing list
> >>>> colug-432 at colug.net
> >>>> http://lists.colug.net/mailman/listinfo/colug-432
> >>>
> >>> _______________________________________________
> >>> colug-432 mailing list
> >>> colug-432 at colug.net
> >>> http://lists.colug.net/mailman/listinfo/colug-432
> >>
> >>
> >>
> >> _______________________________________________
> >> colug-432 mailing list
> >> colug-432 at colug.net
> >> http://lists.colug.net/mailman/listinfo/colug-432
> >>
> >
> > _______________________________________________
> > colug-432 mailing list
> > colug-432 at colug.net
> > http://lists.colug.net/mailman/listinfo/colug-432
> 
> 
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432

More information about the colug-432 mailing list