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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
