Isso significa que alguém configurou o manipulador de sinal para SIGPIPE para SIG_IGN (ignore) e o erro (tentando gravar em um canal sem leitor) é relatado pelo status de saída de write (2) .
No seu caso, o programa na outra extremidade do socket Unix provavelmente está falhando ou saindo inesperadamente. Eu vou olhar primeiro para isso.
pode ser algum ataque sofisticado - muitos programas mal escritos não esperam erros de gravação (2) e não verificam seu valor de retorno. Um processo que sai por causa de um SIGPIPE não é nada especial, e é assim que as coisas devem funcionar. É assim que command | head -5 funciona; Se command ainda quiser gravar coisas no pipeline depois que head -5 tenha saído, ele receberá um SIGPIPE , e tudo terminará bem. Mas se o comando instalar um manipulador de sinal para SIGPIPE ou se o shell de chamada tiver definido um trap '' PIPE (que fará com que ele e seus filhos ignorem o sinal SIGPIPE ), qualquer gravação (2) no canal retornará -1 com errno definido como EPIPE ("canal quebrado"). E os soquetes funcionam da mesma forma que os canos a esse respeito.