Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: User

Persistent ulimit for daemons

 

 

Gentoo user RSS feed   Index | Next | Previous | View Threaded


michael at orlitzky

Aug 1, 2012, 7:41 AM

Post #1 of 9 (783 views)
Permalink
Persistent ulimit for daemons

Is there a blessed method these days for setting the ulimit per-daemon?

The best I've been able to do is a global setting in /etc/rc.conf:

rc_ulimit="-s 1048576"

The entries under /etc/security seem to be ignored when using
`/etc/init.d/foo start`.


caneko at gmail

Aug 1, 2012, 8:27 AM

Post #2 of 9 (711 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On Wed, Aug 1, 2012 at 9:41 AM, Michael Orlitzky <michael [at] orlitzky> wrote:
> Is there a blessed method these days for setting the ulimit per-daemon?
>
> The best I've been able to do is a global setting in /etc/rc.conf:
>
> rc_ulimit="-s 1048576"
>
> The entries under /etc/security seem to be ignored when using
> `/etc/init.d/foo start`.

If you are willing to try, systemd allows you to set not only the
limits for opened files, but also for basically every knob the Linux
kernel has. And to set it per daemon (or unit, in systemd parlance),
of course; for what you want, you would only need to set:

LimitNOFILE=<limit>

in the [Service] section of your unit. If you are interested, all the
relevant documentation is in systemd.exec(5).

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México


michael at orlitzky

Aug 1, 2012, 8:49 AM

Post #3 of 9 (720 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On 08/01/12 11:27, Canek Peláez Valdés wrote:
> On Wed, Aug 1, 2012 at 9:41 AM, Michael Orlitzky <michael [at] orlitzky> wrote:
>> Is there a blessed method these days for setting the ulimit per-daemon?
>>
>> The best I've been able to do is a global setting in /etc/rc.conf:
>>
>> rc_ulimit="-s 1048576"
>>
>> The entries under /etc/security seem to be ignored when using
>> `/etc/init.d/foo start`.
>
> If you are willing to try, systemd allows you to set not only the
> limits for opened files, but also for basically every knob the Linux
> kernel has. And to set it per daemon (or unit, in systemd parlance),
> of course; for what you want, you would only need to set:
>
> LimitNOFILE=<limit>
>
> in the [Service] section of your unit. If you are interested, all the
> relevant documentation is in systemd.exec(5).
>

This is our mail filtering gateway, so I probably won't be willing to
try systemd until the next time we replace the hardware =)

That does sound extremely useful though. I'm planning on converting my
desktops after it gets a little bit more traction.


joost at antarean

Aug 1, 2012, 10:52 PM

Post #4 of 9 (711 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On Wednesday, August 01, 2012 10:41:41 AM Michael Orlitzky wrote:
> Is there a blessed method these days for setting the ulimit per-daemon?
>
> The best I've been able to do is a global setting in /etc/rc.conf:
>
> rc_ulimit="-s 1048576"
>
> The entries under /etc/security seem to be ignored when using
> `/etc/init.d/foo start`.

Michael,

I had to change the "nofiles" ulimit setting for my webserver. For that, I
simply added the settings to the following file:

# cat /etc/security/limits.conf | grep apache
apache hard nofile 4096
apache soft nofile 4096

I would expect the same to work for any other daemon?

HTH,

Joost


michael at orlitzky

Aug 2, 2012, 8:38 AM

Post #5 of 9 (725 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On 08/02/12 01:52, Joost Roeleveld wrote:
> On Wednesday, August 01, 2012 10:41:41 AM Michael Orlitzky wrote:
>> Is there a blessed method these days for setting the ulimit per-daemon?
>>
>> The best I've been able to do is a global setting in /etc/rc.conf:
>>
>> rc_ulimit="-s 1048576"
>>
>> The entries under /etc/security seem to be ignored when using
>> `/etc/init.d/foo start`.
>
> Michael,
>
> I had to change the "nofiles" ulimit setting for my webserver. For that, I
> simply added the settings to the following file:
>
> # cat /etc/security/limits.conf | grep apache
> apache hard nofile 4096
> apache soft nofile 4096
>
> I would expect the same to work for any other daemon?
>

I thought so too, but it doesn't seem to be working (for any daemon, I
even tried with apache just now).

Can you `cat /proc/<pid>/limits` on one of those apache processes? I get
whatever was set for my bash shell rather than what I have in limits.conf.


joost at antarean

Aug 2, 2012, 9:44 PM

Post #6 of 9 (706 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On Thursday, August 02, 2012 11:38:32 AM Michael Orlitzky wrote:
> On 08/02/12 01:52, Joost Roeleveld wrote:
> > On Wednesday, August 01, 2012 10:41:41 AM Michael Orlitzky wrote:
> >> Is there a blessed method these days for setting the ulimit per-daemon?
> >>
> >> The best I've been able to do is a global setting in /etc/rc.conf:
> >> rc_ulimit="-s 1048576"
> >>
> >> The entries under /etc/security seem to be ignored when using
> >> `/etc/init.d/foo start`.
> >
> > Michael,
> >
> > I had to change the "nofiles" ulimit setting for my webserver. For that, I
> > simply added the settings to the following file:
> >
> > # cat /etc/security/limits.conf | grep apache
> > apache hard nofile 4096
> > apache soft nofile 4096
> >
> > I would expect the same to work for any other daemon?
>
> I thought so too, but it doesn't seem to be working (for any daemon, I
> even tried with apache just now).
>
> Can you `cat /proc/<pid>/limits` on one of those apache processes? I get
> whatever was set for my bash shell rather than what I have in limits.conf.

I do get 4096.
Just had another good look at my notes, I also changed the init-file (Added
the ulimit-statement here):
***
start() {
checkconfig || return 1

[ -f /var/log/apache2/ssl_scache ] && rm /var/log/apache2/ssl_scache

ebegin "Starting ${SVCNAME}"
++++ ulimit -n 4096
${APACHE2} ${APACHE2_OPTS} -k start

i=0
while [ ! -e "${PIDFILE}" ] && [ $i -lt ${TIMEOUT} ]; do
sleep 1 && i=$(expr $i + 1)
done

test -e "${PIDFILE}"
eend $?
}

***

I don't think there is a consistent method of making this change more
permanent.

--
Joost


graham at gmurray

Aug 2, 2012, 10:08 PM

Post #7 of 9 (700 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

Michael Orlitzky <michael [at] orlitzky> writes:

> Is there a blessed method these days for setting the ulimit per-daemon?
>
> The best I've been able to do is a global setting in /etc/rc.conf:
>
> rc_ulimit="-s 1048576"
>
> The entries under /etc/security seem to be ignored when using
> `/etc/init.d/foo start`.

Add an rc_ulimits= line to /etc/conf.d/daemon_name


michael at orlitzky

Aug 3, 2012, 9:23 AM

Post #8 of 9 (740 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On 08/03/2012 12:44 AM, Joost Roeleveld wrote:
>
> I do get 4096.
> Just had another good look at my notes, I also changed the init-file (Added
> the ulimit-statement here):
> ***
> ...
> ebegin "Starting ${SVCNAME}"
> ++++ ulimit -n 4096
> ${APACHE2} ${APACHE2_OPTS} -k start

Ah, this is what does it. I would rather not modify the init file in
case someone else updates clamav (the daemon in question) in the future.
Unless they know I've messed with it, they'll just overwrite the changes.


michael at orlitzky

Aug 3, 2012, 9:29 AM

Post #9 of 9 (700 views)
Permalink
Re: Persistent ulimit for daemons [In reply to]

On 08/03/2012 01:08 AM, Graham Murray wrote:
> Michael Orlitzky <michael [at] orlitzky> writes:
>
>> Is there a blessed method these days for setting the ulimit per-daemon?
>>
>> The best I've been able to do is a global setting in /etc/rc.conf:
>>
>> rc_ulimit="-s 1048576"
>>
>> The entries under /etc/security seem to be ignored when using
>> `/etc/init.d/foo start`.
>
> Add an rc_ulimits= line to /etc/conf.d/daemon_name
>

Wow, this works. Thanks!

Gentoo user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.