Re: [PATCH] trace/simple: Fix hang when using simpletrace with fork()

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Feb 26, 2025 at 10:29:59AM +0100, Kevin Wolf wrote:
> Am 26.02.2025 um 09:50 hat Thomas Huth geschrieben:
> > When compiling QEMU with --enable-trace-backends=simple , the
> > iotest 233 is currently hanging. This happens because qemu-nbd
> > calls trace_init_backends() first - which causes simpletrace to
> > install its writer thread and the atexit() handler - before
> > calling fork(). But the simpletrace writer thread is then only
> > available in the parent process, not in the child process anymore.
> > Thus when the child process exits, its atexit handler waits forever
> > on the trace_empty_cond condition to be set by the non-existing
> > writer thread, so the process never finishes.
> > 
> > Fix it by installing a pthread_atfork() handler, too, which
> > makes sure that the trace_writeout_enabled variable gets set
> > to false again in the child process, so we can use it in the
> > atexit() handler to check whether we still need to wait on the
> > writer thread or not.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
> I can see how this would fix the hang, but do we actually get the trace
> events written out somewhere then? Or do we need to make sure that the
> child process has a writer thread, too?
> 
> Of course, the question would then be how the two processes writing into
> the same trace file interact.

In st_set_trace_file, if no explicit filename is given by the user we
use a default filename "trace-$PID", so *if* the atfork handler in
the child were to reset its file after fork it'll get a distinct
filename. Happy days.

If the user provided an explicit filename though, we just use that as
is and would end up with dualling writers and likely data corruption.
While we could blindly append a pid to the user's filename it is 
somewhat unhelpful in the daemonize case to split it across files.

Whether we actually want tracing in a child also possibly depends on
the reason for fork.

If we're forking to daemonize, then we (mostly) want tracing in the
child and (mostly) no longer care about the parent.

If we're forking to exec another app, then we (mostly) want tracing in
the parent and (mostly) no longer care about the child.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|