Can a client determine whether the server has accept()'d a unix socket?

I'm dealing with a buggy server that will sometimes fail to accept() connections (but leaves its listening socket open). This is on Linux with unix domain sockets.

Currently the only way to detect this is that after sending a bunch of data, the buffer fills up and blocks, and the server isn't sending any replies. This long-after-the-fact failure mode is hard to distinguish from other bugs - the server could be unresponsive for other reasons.

Especially for unix domain sockets it seems the kernel should kn开发者_如何学Goow whether accept() has occurred; is there any way to find this out? Can the client block until accept() happens somehow, or at least check whether it has?

This is just for debugging purposes so it can be a little ugly.

---

I'd say that the answer was to change the protocol so that the server speaks first (like SMTP, not like HTTP)

The kernel accepts sockets already before the accept() system call is made; if it never arrives, then the sockets sit around in a waiting state. There is no way to distinguish this from the server accepting the connection but not speaking. This is the way BSD sockets has always worked.

---

Looks like the answer to this is "no"; the kernel offers no way to get at this info.

(change the protocol isn't an answer, since I was debugging a pre-existing unchangeable protocol)