--pgp-sign-Multipart_Sun_Sep_30_13:22:21_2007-1
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
>=20
> On Tue, 14 Aug 2007, Edgar Fu=81=DF wrote:
>=20
> > 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.
>=20
> I didn't check the PR to read about it yet. But what about ...
>=20
> 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=
=20
> would be fine.

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

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>


---------- 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
#
command=3D"/usr/pkg/sbin/${name}"
named_controller_cmd=3D"/usr/pkg/sbin/ndc"

# automatically tune the process priority
#
start_postcmd=3D"renice_named"

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

renice_named()
{
	retries=3D5

	while [ ! -f ${pidfile} -a ${retries} -gt 0 ]; do
		sleep 1
		retries=3D$(($retries - 1))
	done
	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.
		#
		retries=3D5
		while [ ${named_pid} =3D=3D $(cat ${pidfile}) -a ${retries} -gt 0 ]; do
			sleep 1
			retries=3D$(($retries - 1))
		done
		if [ ${retries} -le 0 ]; then
			warn "renice_named: ${pidfile} does not seem to have been updated!"
		fi
		named_pid=3D$(cat ${pidfile})
		renice ${named_niceval} ${named_pid}
	else
		warn "renice_named: cannot open ${pidfile}"
	fi
}

renice_cmd=3D"renice_named"
extra_commands=3D"$extra_commands renice"

--pgp-sign-Multipart_Sun_Sep_30_13:22:21_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iQA/AwUBRv/bTmZ9cbd4v/R/EQKhVACdFnP/ZfAoiGWtybb0mXSjKRlQgqMAoM/p
97O7BF5f8vhttQW+oyVj+FjK
=ifCL
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sun_Sep_30_13:22:21_2007-1--