Anton Aylward wrote:
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,
There is one main process that does the listen()ing and accept()ing, then it hands off the processing to a fork()ed copy.
The Xinetd or the systemd approaches both have a master listener that spawns copies in a good UNIX fashion.
The two approaches are virtually the same.
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.
Right.
My concern with a Xinetd or systemd approach is the termination of the spawned rsyncd process on completion.
As far as I can see, the processes that are inactive never really get started. The rsyncd module they're accessing is running with its own userid, so I can see the forked processes changing the userid. Typically, the inactive processes have not switched userid. THey just keep calling select() with a 60s time-out, waiting for the client to say something. -- Per Jessen, Zürich (3.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org