Hi, running various programs here (kcontrol and xfce-mcs-manager -version 4.2.3, although I doubt this matters much- for instance) results in SIGPIPE termination. Tracing back this problem with ltrace resulted in the following interesting excerpt: rhuizer@mirak ~ $ ltrace -f -S xfce-mcs-manager ... SYS_rt_sigaction(10, 0x7fff1ce28bb0, 0, 8, 0) = 0 <... sigaction resumed> ) = 0 daemon(1, 1, 0, -1, 0 <unfinished ...> SYS_clone(0x1200011, 0, 0, 0x2b7b90c737d0, 4969) = 4970 [pid 4969] SYS_exit_group(0 <unfinished ...> [pid 4969] +++ exited (status 0) +++ --- SIGSTOP (Stopped (signal)) --- --- SIGSTOP (Stopped (signal)) --- SYS_dup(7, 1, 0x7fff1ce289a0, 0x7fff1ce28868, 0x2b7b911fefa0) = 6 SYS_fcntl(6, 2, 1, 0x7fff1ce28868, 0x2b7b911fefa0) = 0 SYS_socket(2, 1, 0, 0x7fff1ce28898, 0x2b7b911fefa0) = 9 SYS_close(7) = 0 SYS_fcntl(9, 1, 1, 0x7fff1ce28878, 0x2b7b911fefa0) = 0 SYS_dup2(9, 7, 1, 0x7fff1ce28868, 0x2b7b911fefa0) = 7 SYS_fcntl(7, 2, 0, 0x7fff1ce28868, 0x2b7b911fefa0) = 0 SYS_close(9) = 0 SYS_write(7, "\025\003\001", 37) = -32 --- SIGPIPE (Broken pipe) --- +++ killed by SIGPIPE +++ I have also provided strace output for a little bit of additional information (the getpeername calls which ltrace does not trace, for whatever dubious reason). rhuizer@mirak ~ $ strace -f xfce-mcs-manager ... rt_sigaction(SIGUSR1, {0x403190, ~[HUP INT QUIT FPE KILL USR1 USR2 TERM CONT STOP TSTP TTOU XCPU VTALRM WINCH PWR RTMIN RT_16 RT_17 RT_18 RT_19 RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_29 RT_30 RT_31], SA_RESTORER|SA_RESTART, 0x2ad857d2eac0}, NULL, 8) = 0 clone(Process 4974 attached child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2ad8585827d0) = 4974 [pid 4973] exit_group(0) = ? Process 4973 detached getsockname(7, {sa_family=AF_INET, sin_port=htons(40665), sin_addr=inet_addr("132.229.231.14")}, [6647348608033095696]) = 0 getpeername(7, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("132.229.231.9")}, [68719476752]) = 0 fcntl(7, F_GETFD) = 0x1 (flags FD_CLOEXEC) dup(7) = 6 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9 close(7) = 0 fcntl(9, F_GETFD) = 0 dup2(9, 7) = 7 fcntl(7, F_SETFD, 0) = 0 close(9) = 0 write(7, "\25\3\1\0 \2*\247-\330\0\345C{\0000\306\326\361\206\220"..., 37) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- Process 4974 detached Reading this it seems we have a write() system call to a descriptor returned from socket(...), which hasn't been initialized any further, thus triggering a SIGPIPE to be sent to the process. Relating this information to running xfce-mcs-manager with the environment containing LD_DEBUG=all (I will attach an excerpt later), I found that the offending piece of code is present in libnss_ldap (version 253). As present in ldap-nss.c:do_drop_connection() int dummyfd = -1, savedfd = -1; /* Under OpenLDAP 2.x, ldap_set_option (..., LDAP_OPT_DESC, ...) is a no-op, so to shut down the LDAP connection without writing anything to the socket, we swap a dummy socket onto that file descriptor, and then swap the real fd back once the shutdown is done. */ savedfd = do_dupfd (sd, -1); dummyfd = socket (AF_INET, SOCK_STREAM, 0); if (dummyfd > -1 && dummyfd != sd) { do_closefd (sd); do_dupfd (dummyfd, sd); do_closefd (dummyfd); } So it is clear in this case that nss_ldap fakes the LDAP connection socket to be a dummy socket() it just allocated. The assumption here is that no further write() calls will be made to this dummy socket, as they would result in SIGPIPE errors. However, when running over SSL, libldap (from openldap 2.3.30-r2) finally calls SSL_shutdown, which in turn sends a shutdown notification over the socket (SSL_CTX_set_quiet_shutdown has not been set in any way), resulting in SIGPIPE dispatch. I have no idea wether this should be patched in libldap or nss_ldap, but I hope this report is enough to allow people to reproduce or understand the nature of the problem. With kind regards, -- Ronald Huizer
Created attachment 107177 [details] LD_DEBUG=all xfce-mcs-manager output
This needs to go to upstream I think.
(In reply to comment #2) > This needs to go to upstream I think. Submitted the bug upstream; it's available at: http://bugzilla.padl.com/show_bug.cgi?id=309
Any reason why you're not ignoring the SIGPIPE? I've run into this issue and that's how I've fixed it. SSL_CTX_set_quiet_shutdown has the disadvantage of not quite cleaning up after it's protocol, it just drops away. It's not leaking a file descriptor in anyway I can see.
(In reply to comment #3) > http://bugzilla.padl.com/show_bug.cgi?id=309 Has ben duped to http://bugzilla.padl.com/show_bug.cgi?id=273 which in turn contains a patch to address the issue. Should that patch be included in ebuilds, at least ~ARCH, before it is incorporated upstream?
257 in CVS now with the SIGPIPE fix, closing.
