On 11/14/2016 07:45 AM, Per Jessen wrote:
with rsync 3.0.7, it had a limited "listen backlog" of only 5, which meant lots of requests were not handled.
At this point I'm coming to believe that you are telling us that rsyncd doesn't work the same way Apache's httpd works, by spawning of a copy of itself to deal with an incoming request, but rather that the rsyncd server is in itself multi-threaded, that is it does not do the "UNIX thing" of cheap COW forks, but as such can only support 5 threads. Perhaps this 'threading instead of spawning" goes back to its Windows/SAMBA concept. The Xinetd or the systemd approaches both have a master listener that spawns copies in a good UNIX fashion. However, once again, the shared memory features come into play; no matter how many copies of rsyncd are spawned by Xinetd or systemd there is only one copy of the code, so the overhead is not great. The data for each instance might be more than the data for each thread of the "five in one instance" but I wouldn't make an issue of it. My concern with a Xinetd or systemd approach is the termination of the spawned rsyncd process on completion. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org