On Sun, 19 Sep 2021 19:11:26 -0700 Martin Dorey <martindo...@gmail.com>
wrote:
> Package: libtirpc3
> Version: 1.1.4-0.4
My production occurrence was always on Stretch, but I'd thought that the
patch might be more easily accepted against a less stale branch. It
applies to Stretch too, where I've just put it into production.
> sendmsg(7, {msg_name={sa_family=AF_INET, sin_port=htons(800),
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=16,
msg_iov=[{iov_base="\0\2:\270\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\371\0\0\0\4"...,
iov_len=36}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0,
ipi_spec_dst=inet_addr("127.0.0.1"), ipi_addr=inet_addr("127.0.0.1")}}],
msg_controllen=32, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)
I don't, today, see EINVAL being returned on Stretch, though I did before.
While successfully sent, the response doesn't get to its intended target
for me today, perhaps ending up at 127.0.0.1 instead of the intended
172.27.5.162 (to use the IP address from the above output).
> Once an rpcbind process has got into this state, it doesn't
> recover without being restarted.
I found, today, that sending Stretch rpcbind the poison pill from a
different machine caused it to recover. I've only seen the problem
exhibited, then, when the poison has been sent locally.
> First enable remote call support.
That was first disabled in Buster, so isn't needed to reproduce the problem
on Stretch.
> rpcinfo -b 100000 4
For my Stretch reproduction today, I have to make this call from a
different computer to the one on which rpcbind is running to see the
problem. Sending a unicast request, like rpcbind -T udp sirius 100000 4,
didn't suffer from the problem for me, at least not today, on Stretch.
