[systemd-devel] [PATCH 1/1] RFC: Set the Default OOM Score from configuration file

Lennart Poettering lennart at poettering.net
Mon May 6 05:35:16 PDT 2013


On Sun, 05.05.13 18:08, Umut Tezduyar (umut at tezduyar.com) wrote:

> On Fri, May 3, 2013 at 4:58 PM, Lennart Poettering
> <lennart at poettering.net>wrote:
> 
> > On Sun, 28.04.13 20:37, Umut Tezduyar (umut at tezduyar.com) wrote:
> >
> > > Hi,
> > >
> > > Should DefaultOOMScore= and DefaultLimit***= be really under [Manager]?
> > > Wouldn't it be better to have an [Exec] section. Or even have [Service],
> > > [Mount],.. sections that can give separate configuration per exec
> > > unit.
> >
> > Hmm, the fields without "Default" prefix are applied to PID1 itself,
> > too, hence they definitely belong into [Manager] I'd say.
> >
> > For the ones prefix with Default, we could probably move them to a new
> > section [Units] or so. But we'd probably have to do that in a compatible
> > way, so this doesn't break existing systems. And that's not too
> > nice. Not sure whether it is worth that effort?
> >
> > > Also, there are many configuration options per exec units that are not in
> > > the system.conf. Are we open taking patches on completing missing
> > > configuration options?
> >
> > Actually, the last time I checked them there were only very few where a
> > default in system.conf really makes sense I think. Which ones do you
> > have in mind?
> >
> 
> Umut: I use ControlGroupPersistent= on one shot unit files to measure their
> cpuacct. I have a generator that adds ControlGroupPersistent dropins for
> oneshot service files when I want to measure the cpuacct. Maybe it would be
> nice to have a DefaultControlGroupPersistent=yes in .conf.

I'd be very careful with that... This would mean that all cgroups
created by instantiated services would stay around, for example those
for each ssh connection. That would be very undesirable, as for each
incoming connection you'd add more left-over cgroups.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list