ltp-syscalls: msgstress03 fails because systemd limits number of processes

Bug #1783881 reported by Thadeu Lima de Souza Cascardo on 2018-07-26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Canonical Kernel Team
Canonical Kernel Team
systemd (Ubuntu)

Bug Description

As systemd limits the number of processes, this test will fail because it can't fork enough processes. That is limited to when the test is run after logging as user 1000, then running sudo. I guess that logging as root may not cause this to happen.

# ./testcases/bin/msgstress03
Fork failed (may be OK if under stress)
Fork failed (may be OK if under stress)
msgstress03 1 TFAIL : msgstress03.c:157: Fork failed (may be OK if under stress)

Changed in linux (Ubuntu Cosmic):
importance: Undecided → Low
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1783881

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Dimitri John Ledkov (xnox) wrote :

What about calling it like this:

$ sudo systemd-run ./testcases/bin/msgstress03

Does that make it pass correctly?

Which resource in particular is exhausted? and can it be toggled somehow using any of ?

Changed in systemd (Ubuntu Cosmic):
status: New → Incomplete

The number of processes (in systemd, tasks).

The command below works for me.

Now, should we change the default on our test systems? Running under systemd-run does not look like a good option.

# systemd-run -p TasksMax=1000000 ./testcases/bin/msgstress03

Dimitri John Ledkov (xnox) wrote :


I recommend you to change your test system.

For example, you can modify /etc/systemd/system.conf and change DefaultTasksMax there. But that is for the systemd started units...
Note that TasksMax these days can accept % values of kernel configured max tasks too, meaning i.e. one can set it to 100%..... The upstream default is 15% and we reverted that, meaning setting it to unlimited.

However something odd is going on.

I wonder if you are actually hitting UserTasksMax instead (which appears to be under-documented).

I wonder if setting UserTasksMax=1000000 in /etc/systemd/logind.conf in the [Login] section, restarting systemd-logind, creating a brand new user session (logout _all_ sessions, and relogin) would actually solve your problem?

ps. Also you can use a "drop-in" instead of modifying a config file, as all config files in systemd support .d `drop-ins` like so:

instead of modifying /etc/systemd/system.conf one can instead install files like these:


with like contents of

Depending on whether you want it to be packaged in a package, be a config file, or be a runtime adjustment.

tags: added: cosmic
no longer affects: systemd (Ubuntu Cosmic)
Po-Hsu Lin (cypressyew) on 2019-06-24
tags: added: amd64 linux-kvm sru-20190603 ubuntu-ltp-syscalls
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers