On Mon, 26.03.12 19:13, Frederic Crozat (fcro...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
