I just got my pipewire process OOM killed:

    [62615.563546] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service,task=pipewire,pid=2550,uid=1000
    [62615.563573] Out of memory: Killed process 2550 (pipewire) total-vm:22028128kB, anon-rss:21793560kB, file-rss:3972kB, shmem-rss:1204kB, UID:1000 pgtables:42860kB oom_score_adj:200

The interesting part is that the process is started with a user-account,
but the ulimits set via /etc/security/limits.conf on this account
(respectively all, because of using "*" as domain there) are not used:


    $ cat /proc/159204/limits
    Limit                     Soft Limit           Hard Limit           Units
    Max cpu time              unlimited            unlimited            seconds
    Max file size             unlimited            unlimited            bytes
    Max data size             3379200000           3891200000           bytes
    Max stack size            unlimited            unlimited            bytes
    Max core file size        0                    unlimited            bytes
    Max resident set          3379200000           3993600000           bytes
    Max processes             127626               127626               processes
    Max open files            1024                 1048576              files
    Max locked memory         4192755712           4192755712           bytes
    Max address space         327680000000         337920000000         bytes
    Max file locks            unlimited            unlimited            locks
    Max pending signals       127626               127626               signals
    Max msgqueue size         819200               819200               bytes
    Max nice priority         0                    0
    Max realtime priority     95                   95
    Max realtime timeout      200000               200000               us

    $ ulimit -aH
    real-time non-blocking time  (microseconds, -R) unlimited
    core file size              (blocks, -c) unlimited
    data seg size               (kbytes, -d) 3800000
    scheduling priority                 (-e) 0
    file size                   (blocks, -f) unlimited
    pending signals                     (-i) 127626
    max locked memory           (kbytes, -l) 4094488
    max memory size             (kbytes, -m) 3900000
    open files                          (-n) 1048576
    pipe size                (512 bytes, -p) 8
    POSIX message queues         (bytes, -q) 819200
    real-time priority                  (-r) 95
    stack size                  (kbytes, -s) unlimited
    cpu time                   (seconds, -t) unlimited
    max user processes                  (-u) 127626
    virtual memory              (kbytes, -v) 330000000
    file locks                          (-x) unlimited

Please have at least /usr/lib/systemd/user/pipewire.service use some
limits to avoid running-away memory allocations -- it's quite boring
to wait for the OOM kill.


The root cause isn't quite clear - I used qpwgraph to connect the
microphone to the speaker output, but there's nothing in the logs
that would help diagnose any further.


Thanks!

Le ven. 22 sept. 2023 à 17:09, Philipp Marek <philipp@marek.priv.at> a écrit :

Would it be possible that firefox was running at this time? Firefox is known
to cause memory leaks in pipewire-pulse. That could explain why the OOM killer
was triggered. See:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840

Best regards,
Dylan

Well, actually I'm not complaining about the process being buggy  - what is worrying me is that the process runs in the logged-on user's context, but without the ulimits (as per /etc/security/limits.conf) or any other limits set up!

At the very least the systemd file should include some sane values for max CPU (resp. cores) and memory usage.


The first one would be a systemd bug, but the latter one surely belongs to this package?!

Le mar. 26 sept. 2023 à 19:54, Philipp Marek <philipp@marek.priv.at> a écrit :

I'm inclined to disagree, I prefer to treat the cause rather than the symptoms.
I don't see any benefit in adding a safeguard to avoid triggering another
safeguard.

And how would you choose these arbitrary limits? What you consider sane limits
will probably not be enough for other legitimate uses.

Pipewire's services are only user services, you can override them by customized
ones that match your needs.

Best regards,
Dylan