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. 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. 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) d) in systemd's own unit files we'll configure much lower settings by default, since we know how many tasks they require. All this together should improve security as it provides a certain amount of per-service protection against fork bombs and suchlike. A single service cannot fork boundlessly anymore, and that's not something services would have to explicitly implement as before, but that would just be there out-of-the-box. Of course, it also has potential to break some services, but I think defaults like 1K and 8K are high enough to make this the exception, not the rule. In summary, I think we gain more by improving security and robustness through putting strict limits on everything we do, than we lose. Users could of course unset these defaults, to lift the limits. And packages could lift the limit in their unit files too, if they know that they are too low for their specific service. Any opinions? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
