S6-IOCONNECT(8)
π s6-ioconnect(8) β the full-duplex bestie
okay so this is the s6-ioconnect page from the System Manager's Manual, and honestly? it's giving "tiny program, big job" energy β¨
π NAME π
s6-ioconnect β perform full-duplex data transmission between two sets of open file descriptors. yes bestie, both directions at once, we contain multitudes π
πΈ SYNOPSIS πΈ
s6-ioconnect [-t millisecs] [-r fdr] [-w fdw]
π¦ DESCRIPTION π¦
okay so here's the vibe: s6-ioconnect reads data from its stdin and writes it as-is to file descriptor 7, which is assumed to be open. no questions, no formatting, just straight piping π«Ά
it also reads data from its file descriptor 6 β also assumed to be open β and writes it as-is to its stdout. yes at the same time. full duplex. main character energy π
when both sides have transmitted EOF and s6-ioconnect has flushed its buffers, it exits 0. clean exit, no drama, slay π
the whole point of s6-ioconnect is to be used together with s6-tcpclient or s6-ipcclient(8) to establish a full-duplex connection between the client and the server β for instance for testing purposes. s6-ioconnect is to s6-tcpclient as cat(1) is to s6-tcpserver: a program that will just echo what it gets. literally the cat of networking, iconic π
fun lore drop: the s6-ioconnect utility was once part of the s6-networking suite, which is why the examples here involve TCP. ngl it's just where it grew up. nevertheless, it can be used with connections across Unix domain sockets as well, and has its place in the s6 package π
β οΈ okay important part, listen up: if one of the endpoints is a socket,s6-ioconnectwill callshutdown(2)on it (for reading or writing, depending on the endpoint) when it needs to transmit EOF. this is a necessary workaround to a misdesign[1] of the socket API π β but it could have unintended consequences when the socket is shared among several processes that expect a persistent connection. most of the time, however, it is a mistake to share a data socket between processes, sos6-ioconnect's behaviour is suited to an overwhelming majority of cases, and the exceptions are specialized enough that they won't need to uses6-ioconnect. fr fr, read that twice π
β¨ OPTIONS β¨
-tmillisecs β if no activity on either side happens for millisecs milliseconds,s6-ioconnectcloses the connection on both ends and exits1. by default, millisecs is0, which means no such timeout. set it if you're the impatient type π-rfdr β use fd fdr for βremoteβ reading instead of fd6. pick your own adventure π§-wfdw β use fd fdw for βremoteβ writing instead of fd7. same energy, other direction π«
π heads up: the-0,-1,-6and-7options are still recognized for compatibility, but do nothing; they are deprecated. they were previously used to tells6-ioconnectthat the local reading, local writing, remote reading and remote writing endpoints, respectively, were sockets β but this is now autodetected. so yeah, they're little ghosts haunting the option parser π»
π₯ SEE ALSO π₯
s6-accessrules-cdb-from-fs(8)s6-accessrules-fs-from-cdb(8)s6-connlimit(8)s6-ipcclient(8)s6-ipcserver(8)s6-ipcserver-access(8)s6-ipcserver-socketbinder(8)s6-ipcserverd(8)
[1] https://cr.yp.to/tcpip/twofd.html β go read it, iykyk π
this man page is ported from the authoritative documentation at: https://skarnet.org/software/s6/s6-ioconnect.html
π AUTHORS π
- Laurent Bercot
- Alexis <flexibeast@gmail.com> (man page port)
and that's the page bestie π brought to you by Debian, dated February 19, 2023 β S6-IOCONNECT(8), ported with love, autodetected with grace πβ¨
π¦ where this page comes from
- nixpkgs unstable: s6 2.15.1.0
- nixpkgs unstable: s6-man-pages 2.14.0.1.4
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms