Control: severity -1 important On Thu, 05 May 2016 20:14:20 +0200 Sebastian Schmidt <y...@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@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?
signature.asc
Description: PGP signature