[systemd-devel] RFC : PATCH: initial implementation of system wide rlimit

Lennart Poettering lennart at poettering.net
Mon Mar 26 10:37:24 PDT 2012


On Mon, 26.03.12 19:13, Frederic Crozat (fcrozat at suse.com) wrote:

> > I am mostly waiting for a usecase here. If somebody makes a good case
> > for hwo they should be useful in system services we can add support for
> > them, but otherwise I am not convinced.
> > 
> > We generally only expose kernel features we think are useful, but if
> > they aren't they are better hidden away.
> 
> Looking at the defaults shipped with openSUSE, some limits are set to
> "sane" soft value  (80% for soft virtual limit, 85% for soft resident
> limit, etc..) and some default have different soft / hard value (fdlimit
> = 8192 (hard), 1024 (soft) ; locklimit = 256KB (hard), 64KB (soft) ).
> With the current implementation, we couldn't ensure such duality. 
> 
> I'll ask around if people have other use cases.
> 
> Another interesting thing I didn't port from SUSE is being able to
> express some of those values as percentage of system memory and not as
> absolute value.

I mean, allowing configuration of separate values for normal user logins
makes sense. For system services not so much. But with these settings
you'd configure the latter, not the former, hence I have trouble seeing
the usefulness of allowing two values to be configured.

pam_limits is usually used to apply resource limits to normal logins.

> > But in general: why this code anyway? We should just let the pointer
> > point to NULL if there is not rlimit set. I.e. only those array entries
> > with non-default values should actually point to something.
> 
> I wanted to show the correct system values (default, when not set in
> systemd) when using systemctl show. Otherwise, they might look as
> infinite value (I was getting that, but I might had a bug there).

But bus_execute_append_rlimits() invokes getrlimit() as necessary to
fill this in. I think it is a good idea to leave the "default" value in
a special default setting as long as possible, hence filling in the
actual values right before passing this over the bus is a good idea.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list