Inquiry: Handling Unix sockets created by glibc/NSS during checkpoint

[ma zhen]

Hi CRaC developers,

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.

During the checkpoint process, I consistently receive a
CheckpointOpenSocketException for a specific file descriptor, which lsof
identifies as a Unix socket.

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.

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.

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:
https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md

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?

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?

Thank you for your time and for developing this fantastic project. Any
guidance you can provide would be greatly appreciated.

Best regards,
mazhen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/crac-dev/attachments/20250915/be6d4b13/attachment.htm>