0

This may be a bit difficult to enumerate succinctly but I will give it my best on my novice understanding of the domain and problem.

I have 2 processes, one stream server who first unlinks, creates a socket descriptor, binds, listens, and accepts on a local unix socket. The job of the server is to accept a connection, send arbitrary data, and also receive arbitrary data. The client process' job is to do the same as the server with the exception of the initial setup; create a socket descriptor, and connect to the unix socket.

Upon launching the server, I can verify the unix socket is being created. Upon launching the client, I receive a connect() error stating the file or directory doesn't exist or invalid. And yes, attempting to locate the unix socket as before, the file no longer exists...

Does anyone know why or where in the bug may lie that is causing this behavior?

If code snippets would be helpful to clarify, I can certainly post those as well.

struct addrinfo * server;
int sockfd;

sockfd = socket( server->ai_family, server->ai_socktype, server->ai_protocol );

if( connect(sockfd, server->ai_addr, server->ai_addrlen) == 0 )
    return sockfd;
else
    perror("connect()");

It's probably also worth noting that I'm using a modified version of getaddrinfo to populate the addrinfo struct for the unix domain specifically.

roschach
  • 8,390
  • 14
  • 74
  • 124
5k1zk17
  • 369
  • 1
  • 4
  • 11
  • 1
    The code for the connection setup should help. – twain249 Apr 10 '12 at 13:52
  • how are you setting up the `server struct`? Also what port and and IP address are you using? – twain249 Apr 10 '12 at 14:05
  • the `addrinfo struct` is populated by the modified `getaddrinfo( "\local", "\tmp\socket", hints, &server)` API to handle unix domain sockets. – 5k1zk17 Apr 10 '12 at 14:23
  • Have you tried running the programs under `strace` so you can see what they actually ask from the kernel? – Simon Richter Apr 10 '12 at 14:43
  • My comment above contains a typo which is not reflected in my code, just in my comment here -- apologies for any confusion -- the above should read (as it does in my code) `getaddrinfo("/local", "/tmp/socket", hints, &server)` – 5k1zk17 Apr 10 '12 at 15:22
  • What OS Unix are you programming on? Some behaviors of the `socket` change from OS to OS. Is your code by any chance inside a loop? – roschach Nov 29 '18 at 10:13

1 Answers1

2

Following the server startup, check that the socket file exists on the client system i.e. make sure that the file you're going to use in the sun_path field of the struct sockaddr_un passed into the connect on the client exists. This entry must match the one that was created in the server and passed into the bind. Also make sure that you are populating the sun_family field in both the client and the server with AF_UNIX.

In the client do not perform any creation/deletion of the socket file - i.e there should not be an unlink anywhere in the client code related to the location of the server socket.

These are the general processes I would follow to ensure that the code is doing the right thing. There is a sample server/client in the old, but still reliable Beej's guide to UNIX IPC which is probably the simplest example you should be comparing to.

Edit Based on the discussion in the comments, it turns out that the custom getaddrinfo call is the culprit in the deletion of the unix socket file. This is because there is server-side logic in the code which checks if hints->ai_flags & AI_PASSIVE is set. If this is the case, then it unlinks the socket file, as it expects the software to be performing a bind (as in be a server). The logic about the AI_PASSIVE flag is codified in the RFC, and in that case, the bind would fail if the file does not exist.

If the AI_PASSIVE flag is specified, the returned address information shall be suitable for use in binding a socket for accepting incoming connections for the specified service (i.e., a call to bind()).

However, the end sentence of that paragraph states:

This flag is ignored if the nodename argument is not null

So it seems like the logic is slightly incorrect in this case of the call getaddrinfo( "/local", "/tmp/socket", hints, &server), as the nodename parameter is not null.

Community
  • 1
  • 1
Anya Shenanigans
  • 91,618
  • 3
  • 107
  • 122
  • Thanks for the comment, I have thoroughly checked the client code for mistakened unlink statements. No bind is called which I presume is what creates the actual socket file on the system. – 5k1zk17 Apr 10 '12 at 14:21
  • Verify that: `ai_family == AF_UNIX`, `af_socktype == SOCK_STREAM` and `ai_protocol == 0` for the `socket` call in the client, and that the server->ai_addr is a valid sockaddr_un structure - i.e. the sun_family corresponds to `AF_UNIX` and the `sun_path` contains the name of the file (without the trailing NULL in the return). And please tell me you're not using a \ in the pathname - it should be `"/tmp/socket"`, otherwise the `"\t"` will be interpreted as a tab – Anya Shenanigans Apr 10 '12 at 14:57
  • haha -- sorry about the typo above, yes the unix path is a forward slash, "/tmp/socket – 5k1zk17 Apr 10 '12 at 15:21
  • You verified that the path is present before the client runs, and also exists when the client terminates and you verified that the sun_path contains the proper pathname of the socket and that the `server->ai_addrlen` is at least strlen(socket) + sizeof(sa_family_t) – Anya Shenanigans Apr 10 '12 at 16:05
  • the path is present before the client but it **DOES NOT** exist when the client terminates from the connect() error... it is this behavior that confuses me. – 5k1zk17 Apr 10 '12 at 16:08
  • the `bind` call is the only thing that creates the file. The `connect` code will not create the file if it doesn't exist. Could the modified getaddrinfo code be removing the file? Check the presence of the file before and after the invocation of getaddrinfo; i.e. make sure that a call of stat("/tmp/socket") succeeds before and after this call. – Anya Shenanigans Apr 10 '12 at 16:28
  • good thought. I mistakenly took for granted the getaddrinfo api code was correct (straight from a well known and respected IPC author) -- there is one unlink code reference in his getaddrinfo routine -- this condition (not sure why?) `if(hints->ai_flags & AI_PASSIVE) unlink(server->sun_path);` I will try using the stat call you suggest and also either remove my AI_PASSIVE flag or comment out this code perhaps and rebuild... – 5k1zk17 Apr 10 '12 at 16:55
  • the `AI_PASSIVE` is server side logic that should not be included in the client - it implies that you're planning on issuing a bind, which, for `AF_UNIX` sockets requires the socket file to not be present, so deleting it seems like a logical step in the getaddrinfo code. Removing the `AI_PASSIVE` flag from the client side getaddrinfo code should suffice to make the code work – Anya Shenanigans Apr 10 '12 at 17:16
  • this makes a lot of sense -- i will try this as soon as i get back -- in the mean time -- thank you for your time! – 5k1zk17 Apr 10 '12 at 17:32
  • Can you update with a pointer to the getaddrinfo routine? Preferably an authoritative source. – Anya Shenanigans Apr 12 '12 at 09:22