This happens about every third time on the two_guests/basic test, and on that test only: we clone() twice, first to spawn a child, then to spawn a thread to check that we can enter the target network namespace. In this thread, we open a file descriptor associated to the target namespace. It might happen that it doesn't exist yet: the kernel can legitimately take its time to create one, after clone(). In this case, at least on a 5.15 Linux kernel, trying to open that file again always yields EACCES, and we get stuck there. This only occurs if we spawn two instances of pasta very close together, as it's done in the two_guests/basic case. See also: https://archives.passt.top/passt-dev/20221104015328.3831630-1-sbrivio@redhat.com/ ...but that patch doesn't actually fix the issue. I think it makes the issue less likely to occur because we wait a bit longer before open() and setns() in the parent. I tried synchronising explicitly (with SIGSTOP, SIGCONT) child and parent, both ways, that doesn't help either. What reliably hides the issue is a sleep(1) at the beginning of pasta_wait_for_ns().
It turns out this is also fixed by commit d8921dafe506 ("pasta: Wait for tap to be set up before spawning command").