On Mon, 5 Aug 2024 17:52:06 +0200 Laurent Vivier <lvivier(a)redhat.com> wrote:On 05/08/2024 16:34, Stefano Brivio wrote:Oops, this is an actual issue: if you run passt in foreground, then err() should _also_ print to stderr, see commit bca0fefa32e0 ("conf, passt: Make --stderr do nothing, and deprecate it")... but it doesn't. That's because we set the log_runtime flag once we're ready (whether we daemonised or not), and then we have: if (debug_print || !log_conf_parsed || (!log_runtime && (log_mask & LOG_MASK(LOG_PRI(pri))))) { (void)vfprintf(stderr, format, ap); if (newline && format[strlen(format)] != '\n') fprintf(stderr, "\n"); } See also https://archives.passt.top/passt-dev/ZnTUrhu8LNWi-krS@zatzit/. Still, while we want to keep pasta usable, we should make sure we print to stderr when passt is running in foreground. I'll send another patch... -- StefanoOn Mon, 5 Aug 2024 16:10:27 +0200 Laurent Vivier <lvivier(a)redhat.com> wrote:Try something: diff --git a/udp.c b/udp.c index a92014806a73..7e179d3b863b 100644 --- a/udp.c +++ b/udp.c @@ -707,6 +707,8 @@ void udp_listen_sock_handler(const struct ctx *c, union epoll_ref ref, if ((n = udp_sock_recv(c, ref.fd, events, mmh_recv)) <= 0) return; + ASSERT(0); + /* We divide datagrams into batches based on how we need to send them, * determined by udp_meta[i].tosidx. To avoid either two passes through * the array, or recalculating tosidx for a single entry, we have to And then generate some UDP traffic. This exits only with: Bad system call Oh, wait, I can see the error in the syslog... but it's not very intuitive as we have the "Bad system call" displayed in the terminal.We use our own implementation of assert() because the glic implementation uses syscalls that aren't in our seccomp filter, see 7a8ed9459dfe ("Make assertions actually useful"). And we replaced it by an err(), followed by an abort() (that is also catched by seccomp). We don't have a coredump or a backtrace but we have at least the error message... only if logging is enabled....wait, err() should always end up somewhere (syslog, log file, or stderr). If you pick stderr, and we closed stderr, then the error will not be reported anywhere (or, possibly worse, on a socket that happens to have number 2). In which case are you losing messages?