If you are using unix socket, you could use socat to see what's going on there. It might require little setting up though.
Aki On 08.09.2017 10:16, Steffan Cline wrote: > I'm not the originator. I'm just trying to do some maintenance on the code to > make it work for CentOS 7. > > I'll check out those two. > > Any ideas on how to check exactly what's sent via the socket? If the EOF is > sent, I know to dig further into the daemon code. > > > Thanks, > Steffan Cline > stef...@hldns.com > 602-793-0014 > >> On Sep 7, 2017, at 11:43 PM, Aki Tuomi <aki.tu...@dovecot.fi> wrote: >> >> Hi! >> >> Nice to hear you are developing this, I'll add it to our wiki if it's >> not there. >> >> Please don't use net_transmit, it's going away. You should use ostream >> and istream instead. >> >> Aki >> >> >>> On 08.09.2017 09:29, Steffan Cline wrote: >>> I’m working on an OS project from github. There are two parts: >>> >>> Dovecot plugin - https://github.com/st3fan/dovecot-xaps-plugin >>> >>> Daemon written in Go - https://github.com/st3fan/dovecot-xaps-daemon >>> >>> >>> >>> # dovecot --version >>> >>> 2.2.10 >>> >>> >>> >>> Both parts worked fine on CentOS 6 but I recently rebuilt them both for >>> CentOS 7 and have run into some errors. >>> >>> >>> >>> The plugin sends a notification over a socket to the daemon. The daemon >>> then processes the request and returns a message to the plugin. >>> >>> >>> >>> The plugin reads the response then closes the socket and at that point, I’m >>> running into an issue. >>> >>> >>> >>> The daemon reports the following: read unix /tmp/xapsd.sock->@: read: >>> connection reset by peer >>> >>> >>> >>> In reading the Go language docs, it says that it will throw the first error >>> it hits before the EOF from the socket. This led me to think that perhaps >>> the plugin was not sending an EOF when closing the socket. >>> >>> >>> >>> I tried to write an EOF to the socket before the close but no change. >>> Everything works between the plugin and daemon right up until the socket >>> close. >>> >>> >>> >>> Is there a way to monitor the stream through the socket so I can see if the >>> plugin is indeed sending the EOF? Knowing that lets me know if I need to >>> chase down the issue in the Go daemon code. >>> >>> >>> >>> I’m no pro with C but I tried. The snippet from the plugin follows: >>> >>> >>> >>> alarm(1); >>> >>> { >>> >>> if (net_transmit(fd, str_data(req), str_len(req)) < 0) { >>> >>> i_error("write(%s) failed: %m", socket_path); >>> >>> ret = -1; >>> >>> } else { >>> >>> char res[1024]; >>> >>> ret = net_receive(fd, res, sizeof(res)-1); >>> >>> if (ret < 0) { >>> >>> i_error("read(%s) failed: %m", socket_path); >>> >>> } else { >>> >>> res[ret] = '\0'; >>> >>> if (strncmp(res, "OK ", 3) == 0) { >>> >>> ret = 0; >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> alarm(0); >>> >>> >>> >>> char stx[1]; >>> >>> stx[0]=(char) 4; >>> >>> //stx[1]='\0'; >>> >>> if ( net_transmit(fd, stx, sizeof(stx) ) < 0 ) { >>> >>> i_error("Error writing EOF"); >>> >>> } >>> >>> >>> >>> //string_t *testEOF= t_str_new(2); >>> >>> //str_append(testEOF, (char*) 4); >>> >>> //if ( net_transmit(fd, str_data(testEOF), str_len(testEOF) ) < 0 ) { >>> >>> // i_error("Error writing EOF"); >>> >>> // } >>> >>> >>> >>> //i_close_fd(&fd); >>> >>> net_disconnect(fd); >>> >>> fd=-1; >>> >>> >>> >>> >>> >>> >>> >>> Thank you, >>> >>> Steffan Cline >>> >>> 602-793-0014 >>> >>>
