Thread: "ulimit -n" in postgresql/pgbouncer init scripts.
Hello!
I'm the devops engineer at Evil Martians (evilmartians.com). We use
postgresql+pgbouncer (9.1.6; 1.5.3) for most of the projects we are
involved in. Till now we maintained our own repository with postgresql
and pgbouncer packages. We want to switch to using your repository.
But we actually need to set open files limit (ulimit -n) for these
processes. In our packages we modified init.d script so that it
invokes "ulimit -n" command.
e.g: for pgbouncer our modification looks like:
…
ULIMIT=1024
# Include pgbouncer defaults if available
if [ -f /etc/default/pgbouncer ] ; then
. /etc/default/pgbouncer
fi
…
case "$1" in
start)
…
ulimit -n $ULIMIT
$SSD --start --chuid $RUNASUSER --oknodo -- $OPTS 2> /dev/null
;;
…
Is it possible for something like this to appear in PGDG packages or
are we doing it wrong?
Thank you.
Kirill
On 12/26/12 6:43 AM, Kirill Kuznetsov wrote: > But we actually need to set open files limit (ulimit -n) for these > processes. In our packages we modified init.d script so that it > invokes "ulimit -n" command. > ULIMIT=1024 > ulimit -n $ULIMIT > Is it possible for something like this to appear in PGDG packages or > are we doing it wrong? That would be B) doing it wrong. Packages aren't the right place to be touching ulimit values. On Debian there are other ways to approach this problem. One way is that you can: -Add lines to /etc/security/limits.conf (or its include files, see [1]) to increase the values for the user like this: postgres hard nofile 1024 postgres soft nofile 1024 Modify with the user names you want to change. * changes all users *except* for the superuser, so that might not impact how you're running things. [1] You can create a file in /etc/security/limits.d/ instead with these changes. That might be a cleaner way to manage things in your environment. It's a good idea to check if any limit changes are happening in that directory too, they can override yours if read in the wrong order. -Edit either /etc/pam.d/su and/or /etc/pam.d/common-session and make sure this line is there: session required pam_limits.so That makes the way PAM is involved in switching users references the new user's ulimit values. There's more information about things like checking if this works as you expect at http://serverfault.com/questions/397553/how-does-ulimit-come-into-effect-on-the-fly and http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Re: Greg Smith 2012-12-26 <50DB32C7.50608@2ndQuadrant.com> > -Edit either /etc/pam.d/su and/or /etc/pam.d/common-session and make > sure this line is there: > > session required pam_limits.so > > That makes the way PAM is involved in switching users references the > new user's ulimit values. I agree that this should be the prefered way to get this resolved, except that pg_ctlcluster doesn't invoke su(1), but does the uid change in pure perl. We should probably fix postgresql-common to use PAM. That said, there's nothing really wrong with editing /etc/default/pgbouncer or /etc/init.d/postgresql to do the ulimit changes. These files are "conffiles", i.e. changes to them will be preserved on package upgrades. (Of course using PAM would be nicer, but we are not there yet.) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
Christoph Berg <myon@debian.org> writes: > That said, there's nothing really wrong with editing > /etc/default/pgbouncer or /etc/init.d/postgresql to do the ulimit One trick here that I've used in the past is that /etc/default/pgbouncer is actually sources as a shell script, so you can add your ulimit command directly in the default file. Works nice. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support