http://bugzilla.suse.com/show_bug.cgi?id=1165351 http://bugzilla.suse.com/show_bug.cgi?id=1165351#c41 --- Comment #41 from Luis Chamberlain <luis.chamberlain@suse.com> --- (In reply to Thomas Blume from comment #40)
(In reply to Luis Chamberlain from comment #39)
However, it seems that the limit for the system daemon is fine and the problem is with the user daemon (systemd --user). In that case the workaround given was wrong indeed.
Please revert the changes in /etc/systemd/system.conf and edit /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
instead. There please set MemoryHigh and MemoryMax limits according to the documentation in the systemd.resource-control manpage.
Please report whether this fixes the ooms.
Nope, the full 30 GiB *and* then swap are eaten up and then the OOM triggers. I rebooted the system after making the changes and trying.
Unfortunately, it seems that the session cleanup was successfull this time. I don't see a user@1000.slice on chivo anymore, so I cannot verify the settings. :( Could you please retry the login on chivo?
Yes is still triggers.
Even better would be if you create a local (non root) user for me so that I can test myself and don't need to nag you all the time.
I did that early on, on February 29 I provided credentials on private comment #1. Let me know if you have issues logging in. The login will take a while, 20-30 seconds because the system is OOM'ing while you log in. It will succeed after the OOM and will let you know after. As I noted earlier as well the best way to visualize the OOM is to use htop: sudo htop --sort-key PERCENT_MEM -d 1 The user test is part of the wheel group and sudo is set with: %wheel ALL=(ALL) NOPASSWD: ALL The credentials apply to both systems, chivo and tuctuc. -- You are receiving this mail because: You are on the CC list for the bug.