Hello, As the subject says, that is what happens on my computer. According to the documentation:
"This is generally a programming error. It can also signal a bug in the s6-fdholder tools, but protocol bugs have usually been wiped out before a s6 release." Operating system is Gentoo, architecture x64_64, GNU libc version 2.23, Linux kernel 4.9.16. Unless I made a mistake, all skarnet.org packages are the latest versions. Steps I've taken to produce the error: # Start an fd-holder and store some FDs $ s6-fdholder-daemon -i rules.d fdholder-socket & $ mkfifo -m 0660 test-fifo $ redirfd -rnb 0 test-fifo s6-fdholder-store fdholder-socket fifo:/home/user/test-fifo $ s6-ipcserver-socketbinder test-socket s6-fdholder-store fdholder-socket unix:/home/user/test-socket $ s6-fdholder-list fdholder-socket fifo:/home/user/test-fifo unix:/home/user/test-socket #Perform a get dump $ execlineb -Pc ' s6-fdholder-getdump fdholder-socket pipeline { env } grep ^S6_' s6-fdholder-getdumpc: fatal: unable to get dump: Protocol error Partial strace (if requested I'll post it complete): execve("/home/guillermo/skarnet/bin/s6-ipcclient", ["/home/guillermo/skarnet/bin/s6-i"..., "fdholder-socket", "/home/guillermo/skarnet/bin/s6-f"..., "pipeline", " env", "", "grep", "^S6_"], [/* 26 vars */]) = 0 ... socket(AF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, sun_path="fdholder-socket"}, 110) = 0 getsockname(3, {sa_family=AF_UNIX}, [110->2]) = 0 dup2(3, 6) = 6 close(3) = 0 dup2(6, 7) = 7 ... execve("/home/guillermo/skarnet/bin/s6-fdholder-getdumpc", ["/home/guillermo/skarnet/bin/s6-f"..., "pipeline", " env", "", "grep", "^S6_"], [/* 28 vars */]) = 0 ... ppoll([{fd=6, events=POLLOUT}], 1, {tv_sec=1152921504606846976, tv_nsec=0}, NULL, 8) = 1 ([{fd=6, revents=POLLOUT}], left {tv_sec=1152921504606846975, tv_nsec=999996660}) sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\1\0\0", iov_len=6}, {iov_base="?", iov_len=1}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 7 recvmsg(6, {msg_namelen=0}, MSG_DONTWAIT|MSG_WAITALL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) ppoll([{fd=6, events=POLLIN|POLLHUP}], 1, {tv_sec=1152921504606846975, tv_nsec=999717297}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {tv_sec=1152921504606846975, tv_nsec=999489651}) recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\t\0\0\0\0\0\0\1\0\0\0\2\0\0\0P\0\2P\0\0\0Y\206;.:w\305"..., iov_len=2047}, {iov_base=NULL, iov_len=0}], msg_iovlen=2, msg_control=[{cmsg_len=24, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3, 4]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_WAITALL|MSG_CMSG_CLOEXEC) = 101 close(4) = 0 close(3) = 0 writev(2, [{iov_base="s6-fdholder-getdumpc: fatal: una"..., iov_len=64}, {iov_base=NULL, iov_len=0}], 2) = 64 exit_group(1) = ? +++ exited with 1 +++ Looking at this it *seems* that the fd-passing part actually succeded, and that the two received FDs are 3 and 4. Thanks, G.