Thanks for the explanations. I will change the pull request as supposed. -----Ursprüngliche Nachricht----- Von: David Vossel [mailto:dvos...@redhat.com] Gesendet: Montag, 22. Dezember 2014 22:25 An: The Pacemaker cluster resource manager Betreff: Re: [Pacemaker] [libqb]Unlink of files bound to sockets
----- Original Message ----- > E.g. this 5 files are created for the sockets. > srwxr-x--x 1 hacluster haclient 0 Dec 19 20:27 > qb-cib_ro-4444-13852-26-event > srwxr-x--x 1 hacluster haclient 0 Dec 19 20:27 > qb-cib_ro-4444-13852-26-response > -rw-rw---- 1 hacluster haclient 24 Dec 19 20:27 > qb-cib_ro-control-4444-13852-26 > srwxr-x--x 1 hacluster haclient 0 Dec 19 20:27 > qb-cib_ro-4444-13852-26-event-tx > srwxr-x--x 1 hacluster haclient 0 Dec 19 20:27 > qb-cib_ro-4444-13852-26-request > > How much should I find? > > Where to find this trick? I got side tracked. I'm sorry. This trick is for the shared memory we use for ipc flow control. This is not related to what you're seeing. Now that I see your file list, the problem is much more obvious. Thanks for being patient with me. > I will try hard to understand it. You are experiencing a bug in libqb for only exists for non-linux systems. I'll explain. Linux has this non-portable concept of abstract sockets. This lets us create sockets without mapping directly to something on the filesystem. Unfortunately solaris doesn't have this feature. Somewhere along the line we introduced a file leak for solaris. Your original patch is actually very close to being correct. Take a look at this function. https://github.com/davidvossel/libqb/blob/master/lib/ipc_socket.c#L53 That's where we set the sun_path. for the '#if defined(QB_LINUX) || defined(QB_CYGWIN)' sun_path is actually being set to ='\0', which indicates we want to use that abstract socket feature. I'm unsure why we continue with what appears to be a useless snprintf to sun_path+1. For the #else we set the sun_path for systems like solaris. This maps the socket to a location on the filesystem like we'd expect, and an unlink will be required. So, for your patch. A more complete solution would be to replace your #if QB_SOLARIS with #if !(defined(QB_LINUX) || defined(QB_CYGWIN)) Would you be interested in submitting that as a pull request to the libqb upstream code on github? I don't have access to a solaris machine at the moment to test with. Please run 'make check' to verify the change. Thanks for the contribution. -- Vossel > -----Ursprüngliche Nachricht----- > Von: David Vossel [mailto:dvos...@redhat.com] > Gesendet: Freitag, 19. Dezember 2014 20:19 > An: The Pacemaker cluster resource manager > Betreff: Re: [Pacemaker] [libqb]Unlink of files bound to sockets > > > > ----- Original Message ----- > > I used the current trunk. > > I could not find the unlink calls. > > > > If domain sockets are used this two methods are used. > > > > In ./lib/ipc_socket.c > > static void > > qb_ipcc_us_disconnect(struct qb_ipcc_connection *c) { > > munmap(c->request.u.us.shared_data, SHM_CONTROL_SIZE); > > unlink(c->request.u.us.shared_file_name); > > right, so here we're doing the unlinking of the shared file. > There's some trick we're using to only have a single file created for > all 3 sockets. > > Is this not working for solaris? > > > > qb_ipcc_us_sock_close(c->event.u.us.sock); > > qb_ipcc_us_sock_close(c->request.u.us.sock); > > qb_ipcc_us_sock_close(c->setup.u.us.sock); > > } > > > > In ./lib/ipc_setup.c > > void > > qb_ipcc_us_sock_close(int32_t sock) > > { > > shutdown(sock, SHUT_RDWR); > > close(sock); > > } > > > > I added in the latter the unlink calls. > > > > -----Ursprüngliche Nachricht----- > > Von: David Vossel [mailto:dvos...@redhat.com] > > Gesendet: Donnerstag, 18. Dezember 2014 18:13 > > An: The Pacemaker cluster resource manager > > Betreff: Re: [Pacemaker] [libqb]Unlink of files bound to sockets > > > > > > > > ----- Original Message ----- > > > > > > > > > I sent yesterday this email to the mailing list of libq > > > 'quarterback-de...@lists.fedorahosted.org'. > > > > > > But there is nearly no activity since august. > > > > i saw the email. i flagged it so it would get a response. > > > > > > > > I use the current trunk of libqb. > > > > > > In qb_ipcc_us_sock_close nd qb_ipcs_us_withdraw of lib/ipc_setup.c > > > sockets are closed. > > > > > > Is there a reason why the files bound to the sockets are not > > > deleted with unlink? > > > > > > Is unlinking not necessary with Linux? > > > > Unlinking is required for linux. > > > > For client/server connections. > > > > qb_ipcc_us_disconnect unlinks on the client side. > > qb_ipcs_us_disconnect unlinks on the server side. > > > > > > > I found thousands of files in statedir=/var/corosync/run after a while. > > > > What version of corosync are you using? There were some reference > > leaks for ipc connections in the corosync code we fixed a year or so > > ago that should have fixed this. > > > > -- David > > > > > > > > > > > I tried this and it seems to work without errors. > > > > > > > > > > > > e.g. > > > > > > void > > > > > > qb_ipcc_us_sock_close(int32_t sock) > > > > > > { > > > > > > #ifdef QB_SOLARIS > > > > > > struct sockaddr_un un_addr; > > > > > > socklen_t un_addr_len = sizeof(struct sockaddr_un); > > > > > > #endif > > > > > > shutdown(sock, SHUT_RDWR); > > > > > > #ifdef QB_SOLARIS > > > > > > if (getsockname(sock, (struct sockaddr *)&un_addr, &un_addr_len) > > > == > > > 0) { > > > > > > if(strstr(un_addr.sun_path,"-") != NULL) { > > > > > > qb_util_log(LOG_DEBUG, "un_addr.sun_path=%s", un_addr.sun_path); > > > > > > unlink(un_addr.sun_path); > > > > > > } > > > > > > } else { > > > > > > qb_util_log(LOG_DEBUG, "getsockname returned errno=%d", errno); > > > > > > } > > > > > > #endif > > > > > > close(sock); > > > > > > } > > > > > > > > > > > > Regards > > > > > > > > > > > > Andreas > > > > > > _______________________________________________ > > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > > > Project Home: http://www.clusterlabs.org Getting started: > > > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > > Bugs: http://bugs.clusterlabs.org > > > > > > > _______________________________________________ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org Getting started: > > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org Getting started: > > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
