Proton startup often crashes in /usr/bin/dash

[kakra]

Please note, I don't have /usr/bin/dash on my system, so it probably comes from the Steam Runtime container.

My system is collecting hundreds of crash instances:

Mon 2026-02-23 23:46:11 CET   56599 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:03:59 CET   59059 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:03:59 CET   59067 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:00 CET   59085 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.1K
Tue 2026-02-24 00:04:00 CET   59102 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:00 CET   59126 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:01 CET   59139 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:01 CET   59154 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.1K
Tue 2026-02-24 00:04:01 CET   59181 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:01 CET   59169 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:01 CET   59202 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:01 CET   59227 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:01 CET   59253 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:01 CET   59278 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:02 CET   59290 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:02 CET   59303 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:02 CET   59326 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:07 CET   59565 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:07 CET   59574 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:07 CET   59590 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:07 CET   59604 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:07 CET   59630 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:08 CET   59639 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:08 CET   59658 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:08 CET   59673 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:37 CET   59834 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:37 CET   59843 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:38 CET   59860 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:38 CET   59873 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:38 CET   59900 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:38 CET   59909 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:38 CET   59928 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:38 CET   59943 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:38 CET   59969 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:39 CET   59982 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.3K
Tue 2026-02-24 00:04:39 CET   59996 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K
Tue 2026-02-24 00:04:39 CET   60017 1000 1000 SIGSYS  present  /usr/bin/dash                                                                                     25.2K

This seems to happen because Proton invocation triggers Steam Runtime container invocation where the real crash most likely happens. Here are two distinct examples but the pattern is repeating:

           PID: 59996 (sh)
           UID: 1000 (kakra)
           GID: 1000 (kakra)
        Signal: 31 (SYS)
     Timestamp: Tue 2026-02-24 00:04:39 CET (12h ago)
  Command Line: sh -c -- $'unset LD_PRELOAD; uname -r'
    Executable: /usr/bin/dash
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-steam\x2dsilent@autostart.service
          Unit: user@1000.service
     User Unit: app-steam\x2dsilent@autostart.service
         Slice: user-1000.slice
     Owner UID: 1000 (kakra)
       Boot ID: 4360a1310777435c93eac0a0d0aac686
    Machine ID: 121b87ca633e8ac0016656680000001b
      Hostname: jupiter
       Storage: /var/lib/systemd/coredump/core.sh.1000.4360a1310777435c93eac0a0d0aac686.59996.1771887879000000.zst (present)
  Size on Disk: 25.2K
       Message: Process 59996 (sh) of user 1000 dumped core.

                Stack trace of thread 59996:
                #0  0x0000562310a40584 __getrlimit (/run/host/usr/lib64/libc.so.6 + 0xfe584)
                ValveSoftware/Proton#1  0x0000562310a98030 __libc_early_init (/run/host/usr/lib64/libc.so.6 + 0x156030)
                ValveSoftware/Proton#2  0x00007fcbcef596d9 dl_main (ld-linux-x86-64.so.2 + 0x216d9)
                ValveSoftware/Proton#3  0x00007fcbcef55ef3 _dl_sysdep_start (ld-linux-x86-64.so.2 + 0x1def3)
                ValveSoftware/Proton#4  0x00007fcbcef57554 _dl_start_final (ld-linux-x86-64.so.2 + 0x1f554)
                ValveSoftware/Proton#5  0x00007fcbcef56448 _start (ld-linux-x86-64.so.2 + 0x1e448)
                ELF object binary architecture: AMD x86-64

           PID: 60017 (sh)
           UID: 1000 (kakra)
           GID: 1000 (kakra)
        Signal: 31 (SYS)
     Timestamp: Tue 2026-02-24 00:04:39 CET (12h ago)
  Command Line: sh -c -- $'unset LD_PRELOAD; sed -n \'s/PRETTY_NAME=\\(.*\\)/\\1/p\' /etc/os-release'
    Executable: /usr/bin/dash
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-steam\x2dsilent@autostart.service
          Unit: user@1000.service
     User Unit: app-steam\x2dsilent@autostart.service
         Slice: user-1000.slice
     Owner UID: 1000 (kakra)
       Boot ID: 4360a1310777435c93eac0a0d0aac686
    Machine ID: 121b87ca633e8ac0016656680000001b
      Hostname: jupiter
       Storage: /var/lib/systemd/coredump/core.sh.1000.4360a1310777435c93eac0a0d0aac686.60017.1771887879000000.zst (present)
  Size on Disk: 25.2K
       Message: Process 60017 (sh) of user 1000 dumped core.

                Stack trace of thread 60017:
                #0  0x000055e6ea802584 __getrlimit (/run/host/usr/lib64/libc.so.6 + 0xfe584)
                ValveSoftware/Proton#1  0x000055e6ea85a030 __libc_early_init (/run/host/usr/lib64/libc.so.6 + 0x156030)
                ValveSoftware/Proton#2  0x00007f60d80cd6d9 dl_main (ld-linux-x86-64.so.2 + 0x216d9)
                ValveSoftware/Proton#3  0x00007f60d80c9ef3 _dl_sysdep_start (ld-linux-x86-64.so.2 + 0x1def3)
                ValveSoftware/Proton#4  0x00007f60d80cb554 _dl_start_final (ld-linux-x86-64.so.2 + 0x1f554)
                ValveSoftware/Proton#5  0x00007f60d80ca448 _start (ld-linux-x86-64.so.2 + 0x1e448)
                ELF object binary architecture: AMD x86-64

Steam system report:

-------------------------------------------------------------
Command: cat /etc/os-release
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.18"

Full report: steam-sysreport-20260224.txt.gz

This may be an issue with missing or non-conforming kernel features (maybe related to seccomp?) - in that case it would be good if Steam / Proton / SRT documented which kernel features are needed/required.

OTOH, it may be that pressure-vessel blocks certain syscalls that SRT relies on during libc init (getrlimit() doesn't seem to succeed).

According to the systemd unit, no seccomp filtering is applied:

# systemctl --user show app-steam-silent@autostart.service | grep -E 'SystemCall|Seccomp|NoNewPrivileges|Restrict'
NoNewPrivileges=no
SystemCallErrorNumber=2147483646
RestrictRealtime=no
RestrictSUIDSGID=no
RestrictNamespaces=no

So this probably means that pressure-vessel itself applied filters.

This may purely be an issue with pressure-vessel not expecting modern glibc (it seems to use the host glibc) which probably uses different syscalls.

The issue exists since several months if not years. It happens on every Steam client startup (it looks like the Steam client itself runs inside a container using SteamAppId=0), and it happens on every shader pre-caching run, and on every game launch.

It doesn't seem to harm how Steam operates but it creates a lot of noise and logging overhead, dumping lots of cores many times a day.

I'll try if PRESSURE_VESSEL_SPAWN_FLAGS="--disable-seccomp" helps.

[smcv]

So this probably means that pressure-vessel itself applied filters

No, pressure-vessel doesn't apply any seccomp filters: it's a container, but not a sandbox (not a security boundary). If a larger component (the Steam client?) applies seccomp filters to subprocesses, and those subprocesses call into a Steam Linux Runtime container, then the seccomp filters can result in terminating pressure-vessel-related processes, but that isn't something that pressure-vessel can solve.

Processes being killed by SIGSYS usually mean seccomp, but it's also possible that there is some other component (SELinux?) that is terminating processes with SIGSYS if they do something that it doesn't like.

If this is seccomp, it would probably be better for the component that uses seccomp (whatever component that is...) to use SCMP_ACT_ERRNO with ENOSYS instead of SCMP_ACT_TRAP or SCMP_ACT_KILL, so that when a syscall is denied, it's made to fail with ENOSYS instead of killing the process with SIGSYS. That way, the calling process can fall back to trying something else. ENOSYS is the error code that's produced if your kernel is too old to implement a particular syscall, so user-space code is already expected to have a reasonable fallback if a recently-added syscall fails that way.

Possibly related to ValveSoftware/steam-for-linux#12913.

I'll try if PRESSURE_VESSEL_SPAWN_FLAGS="--disable-seccomp" helps.

That isn't an environment variable or option that pressure-vessel recognises, so it's unlikely to have any effect (unless some other component is interpreting it, despite its name, for whatever reason). Where did you find that variable name referred to or recommended?

Please note, I don't have /usr/bin/dash on my system, so it probably comes from the Steam Runtime container.

Yes, the various Steam Linux Runtime containers are Debian-derived, so their /bin/sh is dash.

unset LD_PRELOAD; uname -r

For what it's worth, these various shell invocations that are crashing look like MangoHud, so the stack is probably

something that configures seccomp for its children
    \- SteamLinuxRuntime_whatever
        \- some program that gets MangoHud loaded into it
            \- sh

or

SteamLinuxRuntime_whatever
    \- something that configures seccomp for its children
        \- some program that gets MangoHud loaded into it
            \- sh

(Injecting LD_PRELOAD modules like MangoHud into processes that use seccomp to restrict what their child processes can do is pretty much doomed to failure, because seccomp is all about having a very short list of syscalls that you know about and will allow, but LD_PRELOAD modules are arbitrary code, so they can and probably will make syscalls that the host process didn't expect.)

[smcv]

Processes being killed by SIGSYS usually mean seccomp, but it's also possible that there is some other component (SELinux?) that is terminating processes with SIGSYS if they do something that it doesn't like.

Is anything logged in the systemd Journal (if used), auditd log (if used), or syslog when these processes are killed? For example seccomp will usually result in the kernel emitting an audit message that is received by the systemd Journal, something like this:

audit[32150]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=32150 comm="bwrap" exe="/usr/bin/bwrap" sig=31 arch=c000003e syscall=59 compat=0 ip=0x7f35703bad4b code=0x0

(This one is from a different issue and is unrelated to your situation, it's just an example of the sort of thing to look for.)

[kakra]

That isn't an environment variable or option that pressure-vessel recognises, so it's unlikely to have any effect (unless some other component is interpreting it, despite its name, for whatever reason). Where did you find that variable name referred to or recommended?

Well, I tried with AI... And before posting this, it seemingly fixed the problem so I didn't question it any further. But checking today, I still see the crashes, so yes, this var has probably been hallucinated.

My system does not use SE Linux or audit logging, I'm already running the Steam client with -no-cef-sandbox to prevent random crashes from CEF. But this ofc will not be inherited to child processes like games.

With the new version of KDE Plasma 6.6, I now see the crashes in the systray notification. Other than that, and a log in the coredumps, there's nothing special, except what can be seen in the coredumps anyways:

Feb 26 15:38:22 jupiter systemd-coredump[2858505]: [🡕] Process 2858499 (sh) of user 1000 dumped core.

                                                   Stack trace of thread 2858499:
                                                   #0  0x000055d79b424584 __getrlimit (/run/host/usr/lib64/libc.so.6 + 0xfe584)
                                                   #1  0x000055d79b47c030 __libc_early_init (/run/host/usr/lib64/libc.so.6 + 0x156030)
                                                   #2  0x00007ff31c8936d9 dl_main (ld-linux-x86-64.so.2 + 0x216d9)
                                                   #3  0x00007ff31c88fef3 _dl_sysdep_start (ld-linux-x86-64.so.2 + 0x1def3)
                                                   #4  0x00007ff31c891554 _dl_start_final (ld-linux-x86-64.so.2 + 0x1f554)
                                                   #5  0x00007ff31c890448 _start (ld-linux-x86-64.so.2 + 0x1e448)
                                                   ELF object binary architecture: AMD x86-64
Feb 26 15:38:22 jupiter systemd[1]: systemd-coredump@444-12334-2858502_2858503-0.service: Deactivated successfully.
Feb 26 15:38:23 jupiter drkonqi-coredump-processor[2858506]: "/usr/bin/dash" 2858499 "/var/lib/systemd/coredump/core.sh.1000.4360a1310777435c93eac0a0d0aac686.2858499.1772116702000000.zst"

There's nothing related before or after.

I can check if mangohud does anything by disabling it. But yes, mangohud is enabled on most games for me, with a per game setting, not globally via environment. So it wouldn't explain why I can see the crashes when Steam starts.

If it helps, I could enable audit logging in my kernel.