worker: override DefaultTasksMax

The following error

[   67s] Unpacking gcc-7 (7.3.0-16ubuntu3) ...
[   67s] dpkg-deb: unrecoverable fatal error, aborting:
[   67s]  fork failed: Resource temporarily unavailable
[   67s] dpkg: error processing archive /var/cache/apt/archives/gcc-7_7.3.0-16ubuntu3_i386.deb (--unpack):
[   67s]  dpkg-deb --fsys-tarfile subprocess returned error exit status 2
[   67s] dpkg: unrecoverable fatal error, aborting:
[   67s]  fork failed: Resource temporarily unavailable
[   67s] /usr/sbin/debootstrap: 996: /usr/sbin/debootstrap: Cannot fork
[...]

happens since all builds happen in the same cgroup which is limited to 4915 tasks by systemd's per-service defaults. If it reaches a total of 4915 tasks (processes and threads) calls like fork(), clone(), pthread_create() will fail.

Raise the limit to 64000 processes, which is similar to the NPROC rlimit that would be used if the cgroup didn't impose a task limit at all.

This is a short term fix proposed by Simon McVittie, while the long term solution should place each bs_worker instance in its own systemd-managed cgroup. The default task limit of 4915 might then be adequate.

Signed-off-by: Héctor Orón Martínez hector.oron@collabora.com

removed assignee

which is limited to 4915

limited to 4915 tasks by systemd's per-service defaults

while builds have NPROC rlimits (just over 64000)

I'm not suggesting a replacement for this clause because I'm not sure what it means. I think it could probably just be deleted? If a build needs more processes than the limit then of course it's going to fail.

might then be adequated

might then be adequate

(The actual changes look fine.)

It might be worthwhile to mention where the magic number 64000 came from, something like this:

Raise the limit to 64000 processes, which is similar to the NPROC rlimit that would be used if the cgroup didn't impose a task limit at all.

changed the description

merged

mentioned in commit e5219a3a

No real need to do anything about it now since my comments were all minor, but for the future: editing the MR description on Gitlab does not change the commit message. Making the commit message clear is more important than making the MR description clear, because the commit message is what gets written into the git history for future maintainers.

(There is an option to include the full MR description in the merge commit, but it's off by default.)