Comment # 41 on bug 1165351 from Luis Chamberlain

(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.