http://bugzilla.suse.com/show_bug.cgi?id=1165351 http://bugzilla.suse.com/show_bug.cgi?id=1165351#c39 Luis Chamberlain <luis.chamberlain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(luis.chamberlain@ | |suse.com) | --- Comment #39 from Luis Chamberlain <luis.chamberlain@suse.com> --- (In reply to Thomas Blume from comment #37)
(In reply to Luis Chamberlain from comment #36)
I had to reboot the tuctuc system, now the oom is triggering every time on the system upon an ssh login. I didn't do anything other than a reboot.
I took a look in the logs on tuctuc and all ooms I see, were killing the session of user1000. loginctl shows 2 session of user1000 but systemd-cgls doesn't show an user@1000.service nor an init scope for this user. On chivo it is almost the same, most ooms are bound to the user1000 session, only once there was an oom for unbound-anchor.service. user1000 on chivo also doesn't have an user@1000.service and an init scope.
I'm not sure whether this is the result of the oom kill or a special setup for this user.
I haven't done anything custom.
Is user1000 supposed to be a normal user that goes via pam login?
Yes, no NIS stuff.
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. -- You are receiving this mail because: You are on the CC list for the bug.