When you send a UDP datagram with nc, like so: echo foo | nc -u 10.0.0.123 2001 the new version of nc included with FC5 sometimes eats 100% of the CPU. - If you send it to another listening computer (nc -l -u 2001), it returns immediately to the command line. This is as expected. - If you send it to a non-listening (but existing) computer, it hangs, and nc eats 100% of the CPU time. - Finally, if you send it to a non-existent computer, it hangs but does not eat CPU time. In the tables below, I manipulated the first two variables, and the last two variables are the results. I ran 'nc -u -l -p 2001' to make the remote host listen. This is nc 1.84 on FC5: host host eat exists listen hang CPU Y Y N N Y N Y Y N - Y N Contrast this with nc 1.10 on an FC3 installation: host host eat exists listen hang CPU Y Y N N Y N N N N - Y N In all cases, the target host was on the same subnet. I don't know if it would matter if the target was on a different subnet. I personally don't understand why it should hang at all -- shouldn't it just shoot out the UDP datagram and return? But certainly the 100% CPU use is wrong.
Well, you can always specify the timeout value with -w. But I guess the default timeout is rather long. Will look at it.
Created attachment 131865 [details] Fixes endless polling by handling POLLERR event
Thanks for the patch, applied on rawhide with little change.