Had a situation on debian stable sgw firewall running rinetd tcp proxy to redirect smtp, rdp and web traffic on a backup t1 connection where millions of log entries like this were being created:
Dec 1 19:40:21 server-name.domain.com rinetd[28467]: accept(0): Socket operation on non-socket
rinetd and rsyslog were consuming 100% of the cpu, and the disk was filling up at an alarming pace. Stopping rinetd solved the logging problem, but as soon as it was restarted the log slamming continued. The rinetd connection log mentioned something about connections coming from 0.0.0.0 but that did not make any sense. I thought that perhaps a sneaky DoS attack was coming in, but iftop -i eth0 showed very few incoming connections, and a quick deny statement added to the border router showed that no traffic from 0.0.0.0 was coming in.
Total inbound traffic to the server (as seen via iftop and tcpdump) was fairly slow/small in amount, but the log entries were just flying by as fast as they could be created. Clearly the log entries were not related to actual incoming connection attempts; tcpdump was showing no traffic whatsoever hitting the redirected ports and yet the logging blasted on and on.
Finally I realized that apache was binding to the 443 port on all ip addresses - it had a LISTEN 443 command instead of LISTEN A.B.C.D 443 command. MRTG traffic reports was also running on this sgw box. Apache had been installed AFTER rinetd, so apache restarted, and failed to bind to the socket (ip and port 443) that rinetd already had grabbed.
rinetd had been bound to 2 ip aliases that were created on the box. Apache was supposed to be only listening on a different (the main ip address) and this all worked when apache was started after rinetd. But when apache was started first, this caused rinetd to go haywire when it started up.
By giving apache the specific ip to listen on port 443 for, the conflict with rinetd was resolved.