On Fri, 22.01.16 21:17, David Timothy Strauss (da...@davidstrauss.net) wrote:
> Rebooting an old thread now that we're finally testing this out. > > > "strace" should do the job. It should give you a pretty good idea of all > syscalls a process uses. That's what I used when testing SyscallFilters=. > > This turns out to be less useful than it seems. > > There are two major ways to invoke strace, each with caveats: > > - 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. > - 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. > > 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. strace -D from the ExecStart= line should work. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
