FS#47787 - [systemd] USerTaskMax in logind.conf has a too small value
Attached to Project:
Arch Linux
Opened by vnoel (kaouete) - Saturday, 16 January 2016, 15:56 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 13 February 2016, 13:28 GMT
Opened by vnoel (kaouete) - Saturday, 16 January 2016, 15:56 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 13 February 2016, 13:28 GMT
|
Details
Hi, the symptoms of this problem have been reported around
here in #47662 and #47303 but in these bug report, the
problem was the settings of some systemd units.
The problem also manifests directly for the user if he needs to run applications using many threads. I reported the problem on the forum (https://bbs.archlinux.org/viewtopic.php?id=207255) and it led me to the previously cited bug report. I'm wondering if the default value for logind.conf's UserTaskMax of 4096 is not too small. I propose to up it a bit, I don't know what is the perfect value, but I think that even for a normal user that is also a developer for example, you can run into this limit quite rapidly. I myself experienced it during development when running tests on Java code that were using many threads. Also, I don't see the reason for limiting too much this value except in multi-user settings, and it would make sense that the default behaviour is 1) for a one-user installation, which I think is one of the main use of archlinux, and 2) closer to the previous behaviour before this problem appeared. In that case, something like 32000 could be a good value since it is close to the default max number of user processes according to ulimit (-u). Thanks :) |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 13 February 2016, 13:28 GMT
Reason for closing: Fixed
Additional comments about closing: Systemd 229
Saturday, 13 February 2016, 13:28 GMT
Reason for closing: Fixed
Additional comments about closing: Systemd 229
- unclear: my problem is not about systemd unit that are misconfigured as in
FS#47303, but a problem with the user session itself.- incorrect: my problem is not caused by a misconfiguration (as I previously thought, hence the incorrect description) but by a bug in systemd that was fixed upstream (https://github.com/systemd/systemd/pull/1987) but not yet released. The result is that the user session is limited to 512 threads instead of the configured limit of 4096.
Hence, I really think it would be easier to deal with that in a separate issue instead of drowning my comments in the middle of another discussion in
FS#47303. The source and the solution of the problem has nothing to do with this other bug :)Thanks!
Changes will be made in upstream?
Like I already wrote before, I think the pull request you are talking about refers to services started using "systemctl --user" (see "systemctl status user@1001.service" if your uid is 1001). Right now, there is a per-user limit of 512 for such services, which is removed in the pull request.
So we can simply wait for upstream then, I will test this script too on Monday to double check!
➜ ~ ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes 31461
-n: file descriptors 1024
-l: locked-in-memory size (kbytes) 64
-v: address space (kbytes) unlimited
-x: file locks unlimited
-i: pending signals 31461
-q: bytes in POSIX msg queues 819200
-e: max nice 0
-r: max rt priority 0
-N 15: unlimited
I understand your explanation about the commit I referenced being for user services units, systemd is quite complex so I easily get confused with it :)
Still, you agree the results I'm seeing right now are strange… I don't think I have touched anything…
I manually added "TasksMax=infinity" to the end of my /usr/lib/systemd/system/user@.service file and after a reboot everything seems to be working normally. The code for creating threads from stackoverflow now allows me to create about 2700 threads when `systemctl status user-1000.slice` shows about 1400 tasks. Previously I could only create about 300 threads in this situation, which was leading to issues running unit tests for my java code and forking failures when trying to compile a kernel.
Maybe this commit could be added to the current systemd package until the next upstream release is ready?
user.slice (no limit)
-> user-1001.service (limit 4096)
---> session-c6.scope (no limit)
-----> (Here are all the programs that I am running in my session)
---> user@1001.service (limit 512)
-----> (Here are all the services that are started in user scope, such as dbus and pulseaudio)
Does the tree look differently for any of you? Are the programs that you start listed under the session scope?
kaouete: In the ulimits that you post, it seems like the number of file descriptors is quite low. Some people say that this limit also applies to the number of threads that can be opened, although I cannot find any reliable sources on this. Maybe you could try if increasing it changes anything?
That is maybe caused by gnome and the way it launch applications then?
That's really strange because for example, I launch firefox in the same way (using the normal gnome launcher), and it is listed under session-c2.scope...
/
├─init.scope
│ └─1 /sbin/init
├─machine.slice
│ └─machine-qemu\x2dgames.scope
│ └─1524 /usr/sbin/qemu-system-x86_64 -name games .....
├─system.slice
....
└─user.slice
├─user-1000.slice
│ ├─user@1000.service
│ │ ├─dbus.service
│ │ │ ├─ 5433 systemctl status
│ │ │ ├─ 5434 bash /usr/bin/vimpager
I wonder if it should be considered a bug that Gnome runs the terminal in that scope, but I guess with the pull request from https://github.com/systemd/systemd/pull/1987, it doesn’t actually make a difference anymore.
Regarding the issue: In upstream, the default per-user limit has been increased to 12288 (see https://github.com/systemd/systemd/issues/2388).
https://bugzilla.gnome.org/show_bug.cgi?id=761121