Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default

[Antonio Terceiro]

Control: severity -1 important

On Thu, 05 May 2016 20:14:20 +0200 Sebastian Schmidt <yath at yath.de> wrote:
> Package: systemd
> Version: 229-3
> Severity: normal
> Tags: upstream
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> Whilst debugging why Chrome would regularly fail to create new
> threads[1] and zsh couldn’t fork I noticed that:
> - - All affected processes run in the /system.slice/xdm.service cgroup
> - - “systemctl status xdm.service” says “Tasks: 476 (limit: 512)”
> - - The changelog for systemd 228 reads[2]:
> 
>         There's a new system.conf setting DefaultTasksMax= to control
>         the default TasksMax= setting for services and scopes running on
>         the system.
>         […]
>         The setting now defaults to 512, which means services that are
>         not explicitly configured otherwise will only be able to create
>         512 processes or threads at maximum, from this version on.
> 
> - - Nothing in xdm’s PAM configuration would load pam_systemd for creating
>   a session.
> 
> I’m not sure whether using pam_systemd would actually fix that; but
> even then I find this new limit per cgroup at least surprising and
> it apparently breaks a lot of software.
> 
> Sebastian
> 
> 1: https://crbug.com/602002
> 2: https://github.com/systemd/systemd/blob/ccddd104fc95e0e769142af6e1fe1edec5be70a6/NEWS#L373-393

I am seeing some inconsistency in this. On my laptop, I don't see any
limits being applied, even though I am on a fully up to date unstable
(tried both with my main account from a terminal emulator in GNOME, and
from a console login with a freshly created user account):

$ ulimit -u 22988

On a newly created VM, also on unstable, I do see limits, e.g. after
logging in on the console:

terceiro at sid:~$ ulimit -u 384

This has already biten my in 2 occasions:

* for several reasons, the arm64 machines I am using on ci.debian.net
  need a 4.4 kernel and systemd 228, so I several tests are failing on
  arm64 with "Can't fork: resource temporarily unavailable" during
  *package installation*.

* A bug was just reported against ruby2.3 because of a FTBFS on a stretch
  VM, apperently caused by this new systemd behavior (#823604)

I do appreciate the idea of systemd imposing sane limits on tasks, but
this will cause A LOT of breakage in all sorts of places, and we need
figure out a plan forward. Will every package need to start declaring
higher limits explicitly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160506/57dba34c/attachment.sig>