<div dir="ltr">Rebooting an old thread now that we're finally testing this out.<br><div><br>> "strace" should do the job. It should give you a pretty good idea of all<br>
syscalls a process uses. That's what I used when testing SyscallFilters=.<br><br></div><div>This turns out to be less useful than it seems.<br><br>There are two major ways to invoke strace, each with caveats:<br><ul><li>Launch the process with strace. This captures everything from the first syscall to daemonized operation, but it's hard to create an equivalent context and environment versus how the service runs normally. This is especially bad for socket-activated services because 
those may actually use fewer or different syscalls than if they have to 
open their own listener sockets.<br></li><li>
Attach to an existing process. This allows seeing behavior under systemd, but it misses early service startup because the PID is only knowable after the service has started. We've specifically seen issues where some syscalls are only used in early service startup.</li></ul><p>It would be useful if systemd could help packagers, developers, and administrators configure better sandboxes for services by, say, using strace (or equivalent) to capture any unique syscalls in use, starting from the beginning of execution. This wouldn't be the normal mode of operation, but maybe part of a service profiling mode or a property in unit files.<br></p></div></div>