<div dir="ltr"><div dir="ltr"><div>Hi CRaC developers,</div><div><br></div><div>I am currently working on adapting a Java application to support CRaC. I've encountered a specific challenge related to a Unix socket that is preventing successful checkpoint creation.</div><div><br></div><div>During the checkpoint process, I consistently receive a CheckpointOpenSocketException for a specific file descriptor, which lsof identifies as a Unix socket.</div><div><br></div><div>I have conducted a detailed investigation to trace the origin of this socket and found that it is not created directly by my Java application code. Instead, it is created by the underlying glibc library as part of the Name Service Switch (NSS) framework. The call stack, captured using BCC, clearly shows that the socket() call originates from glibc's __nscd_* functions. This happens when the JVM or application triggers a name service lookup (e.g., resolving a user ID). In my specific environment, this results in a Unix socket connection from the Java process to the lwsmd daemon for authentication.</div><div><br></div><div>Because this socket is created and managed within the native C library, the standard approach of implementing a Java-level org.crac.Resource to close and restore it doesn't seem applicable, as my application code has no direct handle or control over its lifecycle.</div><div><br></div><div>I have documented the full analysis, including the error, lsof output, and BCC stack traces, in a detailed write-up which you can find here:</div><div><a href="https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md">https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md</a></div><div><br></div><div>My question is: What is the recommended approach for handling such file descriptors that are opened by underlying native libraries without direct control from the Java application?</div><div><br></div><div>Are there any existing mechanisms, perhaps through advanced file descriptor policies, or any planned features that might address this common scenario? Or is there another workaround that the team would suggest?</div><div><br></div><div>Thank you for your time and for developing this fantastic project. Any guidance you can provide would be greatly appreciated.</div><div><br></div><div>Best regards,</div><div>mazhen</div></div></div>