rsync --daemon not accepting v6 rsync calls. TCPDUMP shows packetflow syn/fin. kill daemon, state left in kernel with netstat -an | grep 873. add inetd entry tcp6. can't bind to port. reboot, problem gone. oddly, ssh and ping6 working, and I see a heap of nd6 neighbour discovery even though the two boxes 'knew' each other when this happened. Fix: notknown How-To-Repeat: not sure I can. looks like sometimes, kernel state for listen() in v6 is stuck even if user process goes away.
Responsible Changed From-To: freebsd-amd64->freebsd-net Reclassify.
Him unfortunately you didn't give any of the output; I guess you lost it with the reboot and don't have a scrollback? I am not exactly sure about the details that happened: 1) you ran rsync standalon in daemon mode 2) you tried to connect by IPv6 which failed? - How? 3) killed rsync 4) what exact state was netstat showing? Was rsync really all gone? 5) you added what exactly to inetd.conf? -- Bjoern A. Zeeb You have to have visions! <ks> Going to jail sucks -- <bz> All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
On 24/01/2011, at 8:03 AM, Bjoern A. Zeeb wrote: > Him >=20 > unfortunately you didn't give any of the output; I guess you lost it > with the reboot and don't have a scrollback? right. sad. >=20 > I am not exactly sure about the details that happened: >=20 > 1) you ran rsync standalon in daemon mode yes. > 2) you tried to connect by IPv6 which failed? - How? SYN, but no reply. client then falls back to nd and thats bizarre, but = what happened. multiple times btw. > 3) killed rsync yes. > 4) what exact state was netstat showing? Was rsync really all gone? tcp6 0 0 *.873 *.* LISTEN not in a FIN_WAIT_2 or TIMEOUT or anything. pstree showed no process in zombie. > 5) you added what exactly to inetd.conf? rsync stream tcp6 nowait root /usr/local/bin/rsync rsyncd = --daemon -6 Look, My gut feel is that this was a one-off.=20 If you get other people saying hmm.. some net trash is left active in = the kernel in V6 sometimes then this might be useful debug of when it = was seen in a kernel, but at this point it cleared across reboot, and I = have no further debug I can give. I can't reproduce. mark it stalled or close? -G=
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped