Comment # 42 on bug 1165351 from Thomas Blume

(In reply to Luis Chamberlain from comment #41)
>
> 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.

Oops, sorry, I've overlooked your testuser.
Now it becomes interesting, systemd-analyze dump shows:

-> Unit user@1001.service:
        Description: User Manager for UID 1001
        Instance: 1001
        Unit Load State: loaded
        Unit Active State: failed
        State Change Timestamp: Thu 2020-03-19 09:12:55 CET
        Inactive Exit Timestamp: Thu 2020-03-19 09:12:39 CET
        Active Enter Timestamp: n/a
        Active Exit Timestamp: n/a
        Inactive Enter Timestamp: Thu 2020-03-19 09:12:55 CET
        May GC: no
        Need Daemon Reload: no
        Transient: no
        Perpetual: no
        Garbage Collection Mode: inactive
        Slice: user-1001.slice
[....]
        -> ExecStart:
                Command Line: /usr/lib/systemd/systemd --user
                        PID: 10907
                        Start Timestamp: Thu 2020-03-19 09:12:39 CET
                        Exit Timestamp: Thu 2020-03-19 09:12:55 CET
                        Exit Code: killed
                        Exit Status: 9
        CPUAccounting: no
        IOAccounting: no
        BlockIOAccounting: no
        MemoryAccounting: yes
        TasksAccounting: yes
        IPAccounting: no
        CPUWeight: 18446744073709551615
        StartupCPUWeight: 18446744073709551615
        CPUShares: 18446744073709551615
        StartupCPUShares: 18446744073709551615
        CPUQuotaPerSecSec: infinity
        CPUQuotaPeriodSec: infinity
        AllowedCPUs: 
        AllowedMemoryNodes: 
        IOWeight: 18446744073709551615
        StartupIOWeight: 18446744073709551615
        BlockIOWeight: 18446744073709551615
        StartupBlockIOWeight: 18446744073709551615
        DefaultMemoryMin: 0
        DefaultMemoryLow: 0
        MemoryMin: 0
        MemoryLow: 0
        MemoryHigh: 18446744073709551615
        MemoryMax: 18446744073709551615
[...]
        TasksMax: 18446744073709551615
[...]
--<

whereas the slice shows:

-->
-> Unit user-1001.slice:
        Description: User Slice of UID 1001
[...]
        MemoryHigh: 3221225472
        MemoryMax: 4294967296
[...]
        TasksMax: 10813
[...]
--<

So, the systemd user instance started in user-1001.slice ignores the limits of
the slice for memory as well as for TasksMax.
I guess this is the root cause of the issue.
Franck, since the systemd user instance is started below the user-1001.slice I
would expect that it respects the memory limit of the slice.
Any idea why it doesn't?