Is that the "systemd spawns dbus which spawns gnome-terminal-server with low ulimits" issue? I ran into that one too https://bbs.archlinux.org/viewtopic.php?id=208658
Ha ! I didn't see this forum post
I reported the bug to gnome btw (again, see the arch issue cited before).
It's a set of interrelated issues:
1) there is gnome spawning things strangely
2) there is systemd overlimiting the strangely spawned things
3) there is systemd overlimiting the normally spawned things
2 and 3 will be fixed in systemd 229 at least.
]]>Based on all the discussion above, I worked around this by creating the file /etc/systemd/system.conf.d/limits.conf (the exact file name doesn't matter) with the contents
[Manager] DefaultLimitNOFILE=65536 DefaultTasksMax=65536
That's a pretty big hammer, but it seems to fix my "fork failed" errors. Maybe others can clarify what versions of linux/systemd will make this hack no longer necessary?
Actually it depends on your situation, if you read the various bug report, you will notice for example that being on Gnome makes a difference when running thread intensive applications in a terminal.
Anyway the main fixes for this problem is coming with systemd 229 that is currently in testing
]]>[Manager]
DefaultLimitNOFILE=65536
DefaultTasksMax=65536
That's a pretty big hammer, but it seems to fix my "fork failed" errors. Maybe others can clarify what versions of linux/systemd will make this hack no longer necessary?
]]>I looked at this bug and the linked systemd commit (awful commit message, btw) and it looks like they just added one line to some service file, exactly as others in this thread did.
It's not any systemd file, it is the one used for the user session: it's not as if the user would decide to use this unit file, it is the one EVERY user will be using for its session.
Not saying I can't modify it myself, just that by default, any user will be limited to 512 processes, which is clearly not enough nowadays
It's a bug in systemd in the sense that this unit file is not really meant to be modified, and that the systemd team's desire was to limit the number of processes to 4096, not 512.
]]>kaouete wrote:I opened another bug report for when the problem is not with a systemd's started application but directly happening to the user: https://bugs.archlinux.org/task/47787
Probably you need to apply the same configuration change to your login manager's service.
No, as described in the first comment of the bug report, the problem comes from systemd actually
]]>I opened another bug report for when the problem is not with a systemd's started application but directly happening to the user: https://bugs.archlinux.org/task/47787
Probably you need to apply the same configuration change to your login manager's service.
]]>In my case the problem came up with docker, and I have solved it now by setting "ThreadsMax=infinity" in my docker.service systemd file. More information here: http://unix.stackexchange.com/a/255603/59955
Thank you! That solved the problem for me.
]]>I'm hitting the limit very early when connected via xrdp vs. a regular desktop session - it's very likely I'm hitting the task limit of 512. I'll try setting "ThreadsMax=infinity" in my xrdp services and see if that fixes it for me.
]]>I did some testing using the C code contained in:
http://stackoverflow.com/questions/3521 … s-at-65528
Using the current 4.3.3 kernel it maxes out at around 4000 threads for me. In 4.2/4.1 LTS it can get to over 31000.
I've also played around with ulimit settings in /etc/security/limits.conf (increasing for all users/root, etc) and also setting DefaultLimitNOFILE in /etc/systemd/system.conf to a high number but that has no affect.
The only sort of reference to the issue I can find is this entry in the mailing list, but there is no followup:
https://lkml.org/lkml/2015/11/24/203
I've switched to the linux-lts kernel in order to avoid the 4.3 kernel for now.
]]>So maybe it is a problem of config, is that it?
]]>