Q: Troubleshoot a systemd service crash because of SystemCallFilter= In OpenSUSE coturn-4.5.2-4.1.x86_64 the .service file contains a seemingly generated part with the allowed capabilities and system calls. They're probably trying to sandbox it in case of vulnerabilities. All is fine except the process is killed almost immediately after start and I had to remove all restrictions one by one to find the culprit line:
SystemCallFilter=~ ... @privileged ...

When the service is killed no useful information is logged to the System Journal.  Only

Main process exited, code=killed, status=31/SYS

The manual says:

@privileged   All system calls which need super-user capabilities (capabilities(7))

I actually want to know the actual system call that failed and what capability is missing.

A: When a service executes a syscall that isn't included in the SystemCallFilter= set, the default action is that the process is terminated with SIGSYS, thus the process dumps a core. Thus, you can inspect the corefile and look up the syscall number there.
Example:
# coredumpctl debug
(gdb) p $rax
157

So 157 is our example syscall number which we can look up in a table, such as:

https://github.com/torvalds/linux/blob/v5.15/arch/x86/entry/syscalls/syscall_64.tbl

i.e.
157 common  prctl           __x64_sys_prctl

Thus, prctl has to be added to SystemCallFilter=.
Another restart might fail because of yet another syscall, thus, it may take some iterations.
You can also check systemd.exec(5) for some plausible missing syscall groups that can be added to SystemCallFilter= to potentially speed up the process.
In addition, one can lookup which syscalls the different groups include exactly in the currently running systemd via:
systemd-analyze syscall-filter


In case the service file also contains SystemCallErrorNumber= then you have to remove it in order to let the process core dump.
