[systemd-devel] RFC: Setting TasksMax= by default
Jóhann B. Guðmundsson
johannbg at gmail.com
Fri Nov 13 07:36:25 PST 2015
On 11/13/2015 01:49 PM, Lennart Poettering wrote:
> Heya!
>
> So, I am tempted to make the following changes to systemd, and was
> wondering about opinions about it:
>
> a) The first change is rather uncontroversial I presume: I'd like to
> set DefaultTasksAccounting=yes in system.conf by default. This
> means we get accounting of the number of tasks per unit enabled by
> default. Effectively this turns on the "pids" cgroup controller for
> all units. According to the cgroups folks this is OK as this
> specific controller is not particularly costly. This means that by
> default "systemctl status" will show a "Tasks: " line then, showing
> the number of tasks in the service. cgtop will be more efficient,
> too, then.
Arguably this should be called system instead of default for system wide
settings where applicable ( you need to keep a clear distinction which
option belongs where and what it affects )
Will people be able to disable this per type unit ( set
"UnitTasksAccounting=yes/no" )
Users sets SystemTasksAccounting=yes in system.conf but turns off task
accounting for b.service while while keeping it for every other type unit ?
Or
Users sets SystemTasksAccounting=no in system.conf but enables task
accounting for a.service while while keeping it disabled for every other
type unit ?
>
> b) I'd like to introduce DefaultTasksMax= that controls the default
> value of the per-unit TasksMax= by default, and would like it to
> set to some value such 1024 out-of-the-box. This will mean that any
> service or scope created will by default be limited to 1024
> tasks. This of course is a change from before that has the
> potential to break some daemons that maintain an excessive number
> of processes or threads. However, I think it's a much better choice
> to raise the limit for them, rather than stay unlimited for all
> services by default. I think 1024 is not particularly low, but also
> not particularly high. Note that the kernel by default limits the
> number of processes to 32K in total anyway.
Should there not be two options "SystemTasksMax" which alters the kernel
default limits and UnitTaskMax which controls the default value of
per-unit ?
>
> c) In logind.conf I intend to add a TasksMax= setting that sets the
> number of tasks for user sessions, and overrides the systemd-wide
> setting for user scopes. It would also be set out-of-the-box, and
> default to something like 8K or so. (Note that this is very similar
> to setting RLIMIT_NPROC via /etc/security/limits.conf, but has the
> benefit of covering also suid binaries, being nicely queriable
> via systemctl status and controllable during runtime via "systemctl
> set-property" and so on)
Should not this be SessionTasksMax= setting? to clearly disquince this
from other task mask settings ( accommodated by SessionTasksAccounting= )
>
> d) in systemd's own unit files we'll configure much lower settings by
> default, since we know how many tasks they require.
>
>
Putting this altogether you have in systemd.conf something along the
lines of
# Enable/disable system wide task accounting
SystemTasksAccounting=yes/no
# Set system wide task limit
SystemTasksMax=32768
# Enables/disable task accounting for type units
UnitTasksAccounting=yes/no
# Set type unit wide task limit
UnitTaskMax=1024
# Enable/disable session task accounting
SessionTasksAccounting=yes/no
# Set session task limit
SessionTasksMax=8000
For type units people could overwrite system wide defaults via
[Unit]
UnitTasksAccounting=yes/no
UnitTaskMax=64
For sessions people could overwrite system wide defaults ( logind.conf ) via
SessionTasksAccounting=yes/no
SessionTasksMax=12000
Status needs to show the current usage and max available and daemon
reload should issue a warning on or fail if the max value for type units
and sessions is set higher than the value of system tasks Max
JBG
More information about the systemd-devel
mailing list