socat CREATE returning Bad file descriptor

Question

I'm trying to build a quick script which listens for one UDP packet, stores it to a file, and exits.

socat to the rescue!

$ socat UDP-RECVFROM:9999 CREATE:/tmp/results_9999
2016/04/08 11:56:59 socat[1955] E read(6, 0x5220d3d0020, 8192): Bad file descriptor

Huh?

The file contains the packet received:

$ cat /tmp/results_9999
SUCCESS on Port 9999

strace seems to show it attempting to read the file it's written to:

recvfrom(5, "SUCCESS on Port 9999\n", 8192, 0, {sa_family=AF_INET, sin_port=htons(34032), sin_addr=inet_addr("192.168.56.102")}, [16]) = 10
recvfrom(3, 0x78ea087b3700, 519, 64, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x78ea087b3d40, 519, 64, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
write(6, "SUCCESS on Port 9999\n", 10)             = 10
recvfrom(3, 0x78ea087b3d40, 519, 64, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x78ea087b3840, 519, 64, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xb675ac8f020, 8192)            = -1 EBADF (Bad file descriptor)
recvfrom(3, 0x78ea087b3840, 519, 64, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
open("/etc/localtime", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=2223, ...}) = 0
mmap(NULL, 2223, PROT_READ, MAP_SHARED, 7, 0) = 0x6c38b6779000
close(7)                                = 0
getpid()                                = 1954
writev(2, [{"", 0}, {"2016/04/08 11:56:41 socat[1954] "..., 84}], 22016/04/08 11:56:41 socat[1954] E read(6, 0xb675ac8f020, 8192): Bad file descriptor
) = 84
exit_group(1)                           = ?
+++ exited with 1 +++

Why would it need to read the file and, if so, why would they open the file write-only?

Is there a switch to fix this or is it a bug?

Answer 1

At this point in time, socat apparently assumes bi-directional communication even when it doesn't make sense.

To override this, use the -u (unidirectional) switch.

e.g.

socat -u UDP-RECVFROM:9999 CREATE:/tmp/results_9999

-- Attribution goes to Gerhard Rieger for clarifying this by email.