Subject: Re: rc.subr: ${name}_ulimit
To: Jeremy C. Reed <>
From: Greg A. Woods <>
List: tech-userlevel
Date: 09/30/2007 13:22:22
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 14 Aug 2007 17:29:30 -0500 (CDT), Jeremy C. Reed wrote:
Subject: Re: rc.subr: ${name}_ulimit
> On Tue, 14 Aug 2007, Edgar Fu=81=DF wrote:
> > May I humbly ask what happened to bin/35530?
> >=20
> > I would like to have a means in rc.subr by which an rc.d script can
> > give ulimits the command is to be run with.
> > I.e., just set foobar_ulimit=3D"-m 999" in rc.d/foobar.
> I didn't check the PR to read about it yet. But what about ...
> Using /etc/rc.conf.d/foobar to place the actual ulimit command you want?

I think it's a little bit more complicated than that, especially for the
case where the whole /etc/rc run happens within one shell interpreter
context.  Trivial attempts to implement rlimit adjustments with ulimit
commands in /etc/rc.conf.d/* files will result in undesirable side effects.

There is possibly a way to do it with "sysctl -w proc.$(<
$pidfile).rlimit.whatever=3DN" for some processes, but as the attached
example shows there can be serious complications which can make this
procedure much less reliable and usable than one might hope.
(${name}_nice wasn't available when I wrote this hack, but just imagine
sysctl(8) command(s) in place of the renice(8) call to imagine how it
must be done to adjust the rlimits of a running daemon process)

Rlimit controls for daemon processes have to be implemented in a way
very much like the way the ${name}_nice option is implemented.

Note also that if "nice" were to grow options to also set the rlimits of
the child process then implementing daemon rlimit adjustments using the
existing ${named}_nice feature of /etc/rc would be trivial.  I've
thought of doing that for a decade or more now.  Maybe the time is now! :-)

And while we're at it, renice should become a tiny wrapper script for
sysctl(8), i.e. the nice value should be settable via sysctl.  :-)

> It seems like it is rarely needed, so just doing it /etc/rc.conf.d/foobar=
> would be fine.

Well, actually I think it's very commonly needed, but the need and
benefits are rarely understood by most system managers.

						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <>
Planix, Inc. <>       Secrets of the Weird <>

---------- example rc.conf.d hack ----------
#	/etc/rc.conf.d/named - how to use the pkg version
# WARNING!  This will not work if you set $named_chrootdir

# automatically tune the process priority

: ${named_niceval:=3D"-2"}


	while [ ! -f ${pidfile} -a ${retries} -gt 0 ]; do
		sleep 1
		retries=3D$(($retries - 1))
	if [ -s ${pidfile} ]; then
		named_pid=3D$(cat ${pidfile})
		# named writes its PID twice -- before and after forking
		# to become a daemon.  We need to wait for the second
		# one, so we try pausing until it changes.  Unfortunately
		# this may not be a sufficient wait on busy systems or
		# systems with very large named configurations to load
		# -- adjust it upwards as necessary.
		while [ ${named_pid} =3D=3D $(cat ${pidfile}) -a ${retries} -gt 0 ]; do
			sleep 1
			retries=3D$(($retries - 1))
		if [ ${retries} -le 0 ]; then
			warn "renice_named: ${pidfile} does not seem to have been updated!"
		named_pid=3D$(cat ${pidfile})
		renice ${named_niceval} ${named_pid}
		warn "renice_named: cannot open ${pidfile}"

extra_commands=3D"$extra_commands renice"

Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: PGPfreeware 5.0i for non-commercial use
MessageID: yr+McrcK/5ddsukiqF+dgmdPuoQTOGr4