There are rare reports of libvirt deadlocking itself which show a fork'd, but not exec'd, child process stuck in localtime_r(). This is because localtime_r() is not an async signal, so if we happened to fork() at the exact time another thread was calling localtime_r() we could get stuck with a stale lock in the child. Although we go to pains to protect the libvirt logging code by acquiring the mutex before forking, this is not sufficient, because some non-logging related code could invoke virTimestamp() which calls localtime_r() too. The only sane approach to fix this is to make our timestamp generation APIs thread safe, by doing a clean impl of gmtime() and strftime() inside libvirt using static buffers and only async safe POSIX apis. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list