Comment # 44 on bug 1165351 from Thomas Blume

(In reply to Luis Chamberlain from comment #43)
> (In reply to Thomas Blume from comment #42)
> > 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.
> 
> Is the theory here still that the real root cause is the tirpc allocations
> for each possible file descriptor, and also, now we are observing the user
> instance ignore user slice limits on memory which *should* in theory contain
> bogus / buggy allocations such as the tirp issue?
> 
> If so then should we really open two bugs ? One for libtirpc and one for
> systemd?

I'm not sure anymore whether there is really a bug in libtirpc.
I've found that it was implemented in 2007 that way by purpose.
So, all current SLES versions carry a libtirpc with this code.
It was never an issue with the correct limits in place.
So, strictly speaking the libtirpc code is not really good, but not a bug
either.
Improving this code would rather qualify for a feature request than for a bug.

On the other hand systemd not respecting the limits of the user slice is
clearly a bug. That must not happen.

> > 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?
> 
> Any idea if we can work around this by forcing this to a low limit somehow?
> 
> And -- what explains why we didn't observe this all the time? I mean even
> though tuctuc no longer exhibits good behaviour, I'm sure any new install of
> Tumbleweed shouldn't be OOM'ing. So a new install should demo a case where
> this is not being observed. So -- *why* is this only observed on some
> systems but not all?

Yes and even more strange is that it doesn't happen for the root  user (user0).
Since it also lives in the user slice, I would expect the same issue.
I can see that even the systemd instance started for user0 doesn't respect the
slice limits:

-->
-> Unit user@0.service:
        Description: User Manager for UID 0
        Instance: 0
        Unit Load State: loaded
[...]
                Command Line: /usr/lib/systemd/systemd --user
                        PID: 14739
                        Start Timestamp: Thu 2020-03-19 18:04:05 CET
        Status Text: Startup finished in 107ms.
        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
        MemorySwapMax: 18446744073709551615
        MemoryLimit: 18446744073709551615
        TasksMax: 18446744073709551615
--<

Still, the login with this user doesn't create an oom.
I have currently no explanation why.