Datagram sockets can only process writes as individual packets with a maximum packet size. Therefore, if the program being run attempts to write(2) more than this size in one call the write will fail and that part of the output will be lost.

This is not usually a problem because the default socket buffer size is usually much higher than the size programs typically write with. For safety, the socket buffer size will be increased to at least PIPE_BUF and BUFSIZ if the default is smaller than these values.

Writes to the socket (on Linux or GNU Hurd) will block until there is capacity available in the socket buffer. If the process uses sendfile(2) then (on Linux) the writes occur in PIPE_BUF sized chunks so it works as normal, but why are you using an interactive program that outputs such large quantities of data?

For more details read the architecture document.


Writes to the socket do not block when the receive buffer of the peer socket is full. The default socket receive buffer is quite small so it will be raised to 512KB (for the send buffer, 256KB). This avoids problems most of the time.

Messages are likely to be lost from programs that write large amounts of data (more than 128..256KB) very quickly or do so inefficiently (1 byte at a time).


Like FreeBSD/OpenBSD/Darwin but the socket buffer can only be raised to 128KB so messages are very likely to be lost if data is written quickly. Unlike the other BSDs, this will result in an error on the receive call so it will not go unreported.


Like FreeBSD/OpenBSD/Darwin but even with a 512KB socket buffer it loses messages of PIPE_BUF size that are written very quickly. Writes of BUFSIZ size are ok because they result in fewer messages.

GNU Hurd

Does not currently have support for returning addresses of Unix sockets, so none of the output works. It may be possible to implement custom pipe-like objects with three file descriptors in user space.

Writes larger than the page size (4KB) are truncated and there’s no way to increase the size of the socket buffer.


Performs as well as Linux but the maximum amount of data that can be streamed quickly is limited by the size of the socket buffer (which will will be raised to 2MB).

There are security issues because the underlying implementation of Unix sockets is a UDP socket on localhost. This presents an opportunity for another process to bind the same port after dtee or the command being run exits, which will allow it to:

  • Write additional input for dtee after the child process has exited (until waitpid(2) is processed).
  • Read output from child processes if the program being run forks into the background (causing dtee to exit).
  • Read output from child processes if dtee is killed.