Submission type

• [X ] Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

≥ 228

Version 228 introduced a DefaultTaskMax=512 limit in 9ded9cd14. Now that this has been released to the world (Ubuntu 16.04 LTS) we're starting to get a lot of fallout from that. We are getting reports about failing MySQL/Percona (https://launchpad.net/bugs/1578080) and RabbitMQ (from our data center admins) even under moderate workloads (as these use a lot of threads), failures of containers (as they all hang off of lxc.service), package builds (https://bugs.debian.org/823530), etc.

In retrospect, having a default limit there was not such a good idea after all: 512 is way too much for most "simple" services, and it's way too little for others such as the ones mentioned above. There is also no particular rationale about "512", so even if we'd bump it to 1024 we'd just make the limit even less useful while still breaking software.

As a contingency plan we'll disable that default at least for the stable distro release, but I think also for devel: It is both much safer and also much more effective in terms of guarding against berserk programs/bugs/unintended fork bombs etc. to set limits in units individually. Once someone looks at one, this is then a great time to also flip on the other resource and privilege limitations that systemd offers, such as CapabilityBoundingSet=, PrivateDevices=, ProtectSystem= etc.

Are you set on your opinion about this default limit, i. e. should we keep this as a downstream change? Or should we revert this upstream too?