[opensuse] inactive rsync clients clogging up rsyncd
I have an rsyncd service for mirroring sanesecurity data. Generally it works very well, but occasionally the rsyncd server will get hung up with many rsyncd processes just waiting on (apparently) inactive clients. This can go on for minutes, possibly hours. I'm running rsyncd via xinetd. The 'timeout' parameter for rsyncd.conf doesn't seem to take effect. I have now taken to automatically killing any rsyncd process running for more than 90seconds, which has improved things tremendously. Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny". I'm happy to post complete configs, but before I clog up the list with that, somebody might recognise the scenario above? -- Per Jessen, Zürich (4.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 13 Nov 2016 18:48:21 +0100
Per Jessen
I have an rsyncd service for mirroring sanesecurity data. Generally it works very well, but occasionally the rsyncd server will get hung up with many rsyncd processes just waiting on (apparently) inactive clients. This can go on for minutes, possibly hours. I'm running rsyncd via xinetd. The 'timeout' parameter for rsyncd.conf doesn't seem to take effect. I have now taken to automatically killing any rsyncd process running for more than 90seconds, which has improved things tremendously.
I have a number of rsync jobs that run regularly. Mine take hours rather than minutes. My jobs are mostly 'receivers' in rsync terminology; the 'senders' are public sites. Mostly my jobs run OK and I use a program called dirvish to manage rsync - it restarts rsync if it fails. That handles the most common failure cases but I do have one site in particular that sometimes hangs with an open but unresponsive connection. Unfortunately the site owners are not very helpful in diagnosing the problem. I used to use rsync 3.06 but now use 3.1.2 and that has had no effect (the other end still uses 3.0.6 though). Some troubles seem to be caused by one particular file since it became just over 1 TB in size. But I really don't understand what causes the failures or the hangs, sorry.
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point. Cheers, Dave
I'm happy to post complete configs, but before I clog up the list with that, somebody might recognise the scenario above?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons. Maybe the intention is to use the firewall instead. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sun, 13 Nov 2016 22:21:10 +0100
"Carlos E. R."
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons. Maybe the intention is to use the firewall instead.
https://download.samba.org/pub/rsync/rsyncd.conf.html list This parameter determines whether this module is listed when the client asks for a listing of available modules. In addition, if this is false, the daemon will pretend the module does not exist when a client denied by "hosts allow" or "hosts deny" attempts to access it. Realize that if "reverse lookup" is disabled globally but enabled for the module, the resulting reverse lookup to a potentially client-controlled DNS server may still reveal to the client that it hit an existing module. The default is for modules to be listable. hosts deny This parameter allows you to specify a list of comma- and/or whitespace-separated patterns that are matched against a connecting clients hostname and IP address. If the pattern matches then the connection is rejected. See the "hosts allow" parameter for more information. The default is no "hosts deny" parameter, which means all hosts can connect. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-13 23:43, Dave Howorth wrote:
I read somewhere that this file is been ignored by many daemons. Maybe the intention is to use the firewall instead.
Not that one. It is /etc/hosts.deny -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 42.2, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2016-11-13 23:43, Dave Howorth wrote:
I read somewhere that this file is been ignored by many daemons. Maybe the intention is to use the firewall instead.
Not that one. It is /etc/hosts.deny
Dave is right, I"m talking about rsyncd.conf, not the tcp_wrappers. I have another example where I'm using "hosts allow", and that works fine. -- Per Jessen, Zürich (1.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/13/2016 01:21 PM, Carlos E. R. wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny". I haven't tried anything like this so can't help at all with this point. I read somewhere that this file is been ignored by many daemons. Maybe
On 2016-11-13 22:10, Dave Howorth wrote: the intention is to use the firewall instead.
I remember reading that tcpwrappers is now deprecated. There are apparently vastly superior ways to control remote access these days. It's well known that iptables is much easier to understand and configure safely than hosts.allow and hosts.deny. I'm also sure that systemd has various target files somewhere that can also serve. After all, why should we continue to use a capability that has been serving us well for 20 and more years when there are new shiny things hanging about to occupy our attention? (do I need a smiley?) Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 01:22, Lew Wolfgang wrote:
On 11/13/2016 01:21 PM, Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
I remember reading that tcpwrappers is now deprecated. There are apparently vastly superior ways to control remote access these days. It's well known that iptables is much easier to understand and configure safely than hosts.allow and hosts.deny. I'm also sure that systemd has various target files somewhere that can also serve. After all, why should we continue to use a capability that has been serving us well for 20 and more years when there are new shiny things hanging about to occupy our attention? (do I need a smiley?)
The problem is, what are those new things? I'm not proficient enough on Iptables to write my own rules, I use SuSEfirewall2 instead. How would I create entries in that file equivalent to host.allow/deny entries? -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 42.2, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2016-11-14 01:22, Lew Wolfgang wrote:
On 11/13/2016 01:21 PM, Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
I remember reading that tcpwrappers is now deprecated. There are apparently vastly superior ways to control remote access these days. It's well known that iptables is much easier to understand and configure safely than hosts.allow and hosts.deny. I'm also sure that systemd has various target files somewhere that can also serve. After all, why should we continue to use a capability that has been serving us well for 20 and more years when there are new shiny things hanging about to occupy our attention? (do I need a smiley?)
The problem is, what are those new things?
I'm not proficient enough on Iptables to write my own rules, I use SuSEfirewall2 instead. How would I create entries in that file equivalent to host.allow/deny entries?
I'm not proficient with SuSEfirewall2, iptables is much easier I find :-) For my purposes, one or more of these would do: iptables -A INPUT -p tcp -i ethx --dport 873 i-s badclient -j REJECT I would just prefer to keep this sort of silly crud "close" to the app having the problem, not in the firewall. -- Per Jessen, Zürich (1.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
I remember reading that tcpwrappers is now deprecated.
Sadly, that code has been left to rot and as from 13.2 has been dropped by openSUSE: even the man pages have disappeared, although openSUSE still uses it with some packages, e.g. nut. Lew Wolfgang also wrote:
There are apparently vastly superior ways to control remote access these days. It's well known that iptables is much easier to understand and configure safely than hosts.allow and hosts.deny.
(do I need a smiley?)
You certainly do after making such a claim. iptables is on a par with sendmail for configuration complexity, whereas TCP wrappers as originally written by Wietse Venema in 1990 was a simple declarative approach. On Mon, 14 Nov 2016, Carlos E. R. wrote:
I'm not proficient enough on Iptables to write my own rules, I use SuSEfirewall2 instead. How would I create entries in that file equivalent to host.allow/deny entries?
I was a keen user of /etc/hosts.allow and faced the same problem when SSH abandoned TCP Wrappers. I wrote a Bash script to convert the hosts.allow rules to ipsets, and to provide the glue function for iptables. The documentation and download are at http://rogerprice.org/hosts.allow/ The script covers most but not all of TCP Wrappers. For example it will forbid all traffic from a ccTLD such as ".fr" but it is not possible to specify domains directly as ".gouv.fr". The script has been tested with sets of up to 150000 IPv4 sub-nets. Health and Safety Warning: The use of custom extensions to the SUSE firewall SuSEfirewall2 is not supported by SUSE. Roger -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Price wrote:
Lew Wolfgang wrote:
I remember reading that tcpwrappers is now deprecated.
Sadly, that code has been left to rot and as from 13.2 has been dropped by openSUSE:
FYI, tcp wrappers (tcpd and libwrap) is still present in Leap421 and Leap422. As far I can tell, it's also still avaialble in 13.2: # rpm -qi libwrap0 Name : libwrap0 Version : 7.6 Release : 884.1.2 Architecture: i586 Install Date: Wed 07 Jan 2015 09:42:04 CET Group : System/Libraries Size : 36092 License : BSD-3-Clause Signature : RSA/SHA256, Thu 25 Sep 2014 08:51:04 CEST, Key ID b88b2fd43dbdc284 Source RPM : tcpd-7.6-884.1.2.src.rpm Build Date : Thu 25 Sep 2014 08:50:44 CEST Build Host : cloud129 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : ftp://ftp.porcupine.org/pub/security/index.html Summary : The TCP wrapper library Description : This package contains a library which implements classifying incoming requests (connections) based upon rule exclusion files (/etc/hosts.*). Distribution: openSUSE 13.2
even the man pages have disappeared, although openSUSE still uses it with some packages, e.g. nut.
The man page "hosts_access" is provided by tcpd, it hasn't gone anywhere. -- Per Jessen, Zürich (2.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Price wrote:
I was a keen user of /etc/hosts.allow and faced the same problem when SSH abandoned TCP Wrappers. I wrote a Bash script to convert the hosts.allow rules to ipsets, and to provide the glue function for iptables. The documentation and download are at http://rogerprice.org/hosts.allow/
Roger, I'd like to add a comment to a bit of that article:
Since that release users of TCP wrappers must now look for other means of securing services such as openssh. A common response is to say "Use the iptables firewall",
Personally I have never used hosts.{allow,deny} to secure any sshd service. I find these two are much better and much more effective methods: a) use a public/private key setup. b) change the ssh port. Just my opinion. -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway. -- Per Jessen, Zürich (1.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd. I thought the problem with inactive clients might be some incompatibility thing between server and client, so I upgraded rsync to the latest (3.1.12), but this made no difference. I am not sure what the "timeout" config option in rsyncd.conf is really meant to do, but it doesn't help in this situation. Instead, I've written a little wrapper that'll send a SIGALRM to the rsyncd instance after 3 minutes. Admittedly a bit crude, but there is only 40-50M to rsync (which would rarely be upgraded all at once), 3 minutes should be plenty for any client to complete the sync. -- Per Jessen, Zürich (2.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 11:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Why don't you run rsyncd as daemon? Maybe it does a difference. Oh, what you say is about the same as I do, it would be xinet which would do the denying.
I thought the problem with inactive clients might be some incompatibility thing between server and client, so I upgraded rsync to the latest (3.1.12), but this made no difference. I am not sure what the "timeout" config option in rsyncd.conf is really meant to do, but it doesn't help in this situation.
Instead, I've written a little wrapper that'll send a SIGALRM to the rsyncd instance after 3 minutes. Admittedly a bit crude, but there is only 40-50M to rsync (which would rarely be upgraded all at once), 3 minutes should be plenty for any client to complete the sync.
Crude :-))) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-11-14 11:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Why don't you run rsyncd as daemon? Maybe it does a difference.
with rsync 3.0.7, it had a limited "listen backlog" of only 5, which meant lots of requests were not handled. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 13:45, Per Jessen wrote:
Carlos E. R. wrote:
Why don't you run rsyncd as daemon? Maybe it does a difference.
with rsync 3.0.7, it had a limited "listen backlog" of only 5, which meant lots of requests were not handled.
Sorry, what's a backlog in this sense? Number of clients simultaneously requesting a connection? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-11-14 13:45, Per Jessen wrote:
Carlos E. R. wrote:
Why don't you run rsyncd as daemon? Maybe it does a difference.
with rsync 3.0.7, it had a limited "listen backlog" of only 5, which meant lots of requests were not handled.
Sorry, what's a backlog in this sense? Number of clients simultaneously requesting a connection?
It's the number of pending connections for the listen() call. from the man page: "int listen(int sockfd, int backlog)" "The backlog parameter defines the maximum length [of] the queue of pending connections". -- Per Jessen, Zürich (3.8°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
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
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
On 2016-11-14 10:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Do you have a 'list' parameter set to false? Nobody has commented on my man page extract, so I'm not sure it has been understood. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On 2016-11-14 10:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Do you have a 'list' parameter set to false?
This rsyncd has 3 modules, two of them have "list = false", but not the one this is about.
Nobody has commented on my man page extract, so I'm not sure it has been understood.
I did read it, but I'm not sure what you meant with it? -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 12:49, Per Jessen wrote:
Dave Howorth wrote:
On 2016-11-14 10:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote:
On Sun, 13 Nov 2016 18:48:21 +0100 Per Jessen <> wrote:
> Also, rsyncd seems to ignore my "hosts deny" setting - I tried > refusing access to a couple of the most frequently hanging > clients, but afaict, rsyncd just ignores "hosts deny".
I haven't tried anything like this so can't help at all with this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Do you have a 'list' parameter set to false?
This rsyncd has 3 modules, two of them have "list = false", but not the one this is about.
Nobody has commented on my man page extract, so I'm not sure it has been understood.
I did read it, but I'm not sure what you meant with it?
Sorry, I thought it was obvious. To my reading, unless there is a list = false then hosts deny is disregarded. Which I think explains your problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On 2016-11-14 12:49, Per Jessen wrote:
Dave Howorth wrote:
On 2016-11-14 10:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
On 2016-11-13 22:10, Dave Howorth wrote: > On Sun, 13 Nov 2016 18:48:21 +0100 > Per Jessen <> wrote:
>> Also, rsyncd seems to ignore my "hosts deny" setting - I tried >> refusing access to a couple of the most frequently hanging >> clients, but afaict, rsyncd just ignores "hosts deny". > > I haven't tried anything like this so can't help at all with > this point.
I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Do you have a 'list' parameter set to false?
This rsyncd has 3 modules, two of them have "list = false", but not the one this is about.
Nobody has commented on my man page extract, so I'm not sure it has been understood.
I did read it, but I'm not sure what you meant with it?
Sorry, I thought it was obvious. To my reading, unless there is a list = false then hosts deny is disregarded. Which I think explains your problem.
That does not really make sense to me - with list=true, a module is listed when the client does not specify one, with list=false, it is not listed. I would think I should be able to use "hosts deny" regardless of whether a module is listed. I read the man page slightly differently - if list=false is specified, and a client is denied access (by way of hostsallow/deny), rsyncd will pretend the module doesn't exist (rather than just refuse access). -- Per Jessen, Zürich (3.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 19:07, Per Jessen wrote:
Dave Howorth wrote:
On 2016-11-14 12:49, Per Jessen wrote:
Dave Howorth wrote:
On 2016-11-14 10:31, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
> On 2016-11-13 22:10, Dave Howorth wrote: >> On Sun, 13 Nov 2016 18:48:21 +0100 >> Per Jessen <> wrote: > >>> Also, rsyncd seems to ignore my "hosts deny" setting - I tried >>> refusing access to a couple of the most frequently hanging >>> clients, but afaict, rsyncd just ignores "hosts deny". >> >> I haven't tried anything like this so can't help at all with >> this point. > > I read somewhere that this file is been ignored by many daemons.
You're right, in many apps tcp_wrappers is no longer compiled in, but this "hosts deny" directive is part of rsyncd.conf.
> Maybe the intention is to use the firewall instead.
Which I will probably do, but it's annoyiung when rsyncd (apparently) has the functionality anyway.
I think I know why "hosts deny" in rsyncd.conf does not work - the incoming connection is handled by xinetd, then passed to rsyncd.
Do you have a 'list' parameter set to false?
This rsyncd has 3 modules, two of them have "list = false", but not the one this is about.
Nobody has commented on my man page extract, so I'm not sure it has been understood.
I did read it, but I'm not sure what you meant with it?
Sorry, I thought it was obvious. To my reading, unless there is a list = false then hosts deny is disregarded. Which I think explains your problem.
That does not really make sense to me - with list=true, a module is listed when the client does not specify one, with list=false, it is not listed. I would think I should be able to use "hosts deny" regardless of whether a module is listed.
I read the man page slightly differently - if list=false is specified, and a client is denied access (by way of hostsallow/deny), rsyncd will pretend the module doesn't exist (rather than just refuse access).
Ah, I think you're right. Sorry for the noise. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/13/2016 12:48 PM, Per Jessen wrote:
I'm running rsyncd via xinetd.
I've long ago discontinued the use of xinetd. Back in the mists of history, the - now depreciated - inetd was a move on the part of some <strike> hackers</strike> to eliminate the need for having a mass of active daemons each listening on the relevant port. Xinetd was meant to be a clean=up of that which incorporated some feature like "TCP Wrappers". IYR, that was Wietse Venema's "shim" that implemented the ACL. Yes that was (supposed to) use /etc/hosts.allow and /etc/hosts.deny. My only observation is that its easy to get the entries for that wrong. Do check what is in /var/log/secure and /var/log/messages. The entries are supposed to be in the format <daemon list>: <client list> [: <option>: <option>: ...] One common mistake is to use the name of the service rather than the name of the daemon process. Remember, you can run Xinetd in debug mode to find out in more detail what's going on. =============== You don't mention what version of the OS you are using. If it is a later model, you may find it more manageable to use a systemd unit rather than a an Xinetd descriptor. Why? Well in one sense systemd is already doing what inetd & xinetd did, it listens on a whole bunch of sockets for requests and then fires up services. Just as Xinetd has a separate config file for each socket that it listens on, so does system have "unit" files for each socket it listens on. If you are running a later model Linux you are already running systemd, so why run Xinetd as well? You are just adding complexity. The primary reference is http://0pointer.de/blog/projects/inetd.html It uses sshd as an example but its easy enough to ... <quote> That said, there are a couple of useful features that systemd does not support, for example IP ACL management. However, most administrators will probably agree that firewalls are the better solution for these kinds of problems and on top of that, systemd supports ACL management via tcpwrap for those who indulge in retro technologies like this. On the other hand systemd also provides numerous features xinetd does not provide, starting with the individual control of instances shown above, or the more expressive configurability of the execution context for the instances. I believe that what systemd provides is quite comprehensive, comes with little legacy cruft but should provide you with everything you need. https://together.jolla.com/question/19492/rsync-daemon-mode-as-a-systemd-soc... You may find this https://lists.fedoraproject.org/pipermail/users/2011-November/408706.html more interesting or more relevant since it also discusses ACL. Oh, and *DO read the followups! You *MOST* *DEFINITELY* want the version that listens on a socket to implement a per-service instance if you want systemd to work the way Xinetd did. That means tou have to tell it about the socket with a .socket unit file. Given all that, I'm running 13.2 and I see I have a /usr/lib/systemd/system/rsyncd.service but that only starts the whole daemon, it doesn't do the systemd socket listener thing described above. Perhaps the package maintainers need a wakeup call :-) -- A military operation involves deception. Even though you are competent, appear to be incompetent. Though effective, appear to be ineffective. Sun-tzu, The Art of War. Strategic Assessments -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 11/13/2016 12:48 PM, Per Jessen wrote:
I'm running rsyncd via xinetd.
I've long ago discontinued the use of xinetd.
Ditto, but in this case xinetd works better than rsyncd. My rsyncd on this box is a little old, so does not support the "listen backlog" cofig directive. Running rsyncd with xinetd allows the system to do a lot more work.
Remember, you can run Xinetd in debug mode to find out in more detail what's going on.
Afaict, xinetd is not part of the problem. xinetd just forks rsyncd for every new connection, and I would expect rsyncd to deny clients matching my "hosts deny" setting from rsyncd.conf.
===============
You don't mention what version of the OS you are using.
Backlevel as usual. 11.4 I think.
If it is a later model, you may find it more manageable to use a systemd unit rather than a an Xinetd descriptor.
Why? Well in one sense systemd is already doing what inetd & xinetd did, it listens on a whole bunch of sockets for requests and then fires up services.
When I upgrade or move this service, I expect to just revert to rsyncd. Both xinetd and systemd are superfluous in this scenario. -- Per Jessen, Zürich (1.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 08:17, Per Jessen wrote:
Anton Aylward wrote:
Remember, you can run Xinetd in debug mode to find out in more detail what's going on.
Afaict, xinetd is not part of the problem. xinetd just forks rsyncd for every new connection, and I would expect rsyncd to deny clients matching my "hosts deny" setting from rsyncd.conf.
I think that in this case you would need the old method, /etc/hosts.deny. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11/14/2016 02:17 AM, Per Jessen wrote:
[...] Running rsyncd with xinetd allows the system to do a lot more work.
Do you mean 'requires', as in 'do work that alternatives might not require and so places a greater load on the system" or do you mean "offers more options and flexibility" ??
Afaict, xinetd is not part of the problem. xinetd just forks rsyncd for every new connection, and I would expect rsyncd to deny clients matching my "hosts deny" setting from rsyncd.conf.
I'm leaning to the belief that Xinetd *is* the problem becuase it is Xinetd that sees the connection information and should be handling the allow/deny, and that the relevant information is lost by the time rsyncd gets the connection. -- 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
On 2016-11-14 13:29, Anton Aylward wrote:
On 11/14/2016 02:17 AM, Per Jessen wrote:
Afaict, xinetd is not part of the problem. xinetd just forks rsyncd for every new connection, and I would expect rsyncd to deny clients matching my "hosts deny" setting from rsyncd.conf.
I'm leaning to the belief that Xinetd *is* the problem becuase it is Xinetd that sees the connection information and should be handling the allow/deny, and that the relevant information is lost by the time rsyncd gets the connection.
Yep. But... I see the advantage of xinetd when the target service is used sparsely. Once the job is finished, the rsyncd daemon exits and frees resources. But if it is used regularly, why not use the rsync daemon directly? Another thing that I do not know, is what happens when there are two or more clients simultaneously. Do you get as many daemons running? In that case, you start to lose the advantage. Me, I also have rsynd via xinetd. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
Another thing that I do not know, is what happens when there are two or more clients simultaneously. Do you get as many daemons running? In that case, you start to lose the advantage.
Both xinetd and rsyncd will start a server per client. My setup peaks about once an hour with toward 400 clients. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2016 07:50 AM, Per Jessen wrote:
Both xinetd and rsyncd will start a server per client. My setup peaks about once an hour with toward 400 clients.
By Apache, web server terms, that is nothing. 400 minute, day in, day you, is still nothing for an Apache server. What machine is this? What engine/memory? -- 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
Anton Aylward wrote:
On 11/14/2016 07:50 AM, Per Jessen wrote:
Both xinetd and rsyncd will start a server per client. My setup peaks about once an hour with toward 400 clients.
By Apache, web server terms, that is nothing. 400 minute, day in, day you, is still nothing for an Apache server.
Sure. Shouldn't be much for an rsync server either, even if the amounts could be a lot more. The directory holds 40-50M, but the actual data sent (whatever has changed) is usually less than 300kb.
What machine is this? What engine/memory?
A elderly HP Proliant, 2 x 2.8GHz Xeons, 2Gb RAM, GiGE interfaces. It's mostly idling. -- Per Jessen, Zürich (3.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2016 08:29 AM, Per Jessen wrote:
What machine is this? What engine/memory? A elderly HP Proliant, 2 x 2.8GHz Xeons, 2Gb RAM, GiGE interfaces. It's mostly idling.
Ah, yes, "mostly". Rather like drowning in that river of "average" depth less than 1 meter, except when you step into the hole that is 10 meters deep. Its the "peak" handling capability that's the issue :-) -- 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
Anton Aylward wrote:
On 11/14/2016 08:29 AM, Per Jessen wrote:
What machine is this? What engine/memory? A elderly HP Proliant, 2 x 2.8GHz Xeons, 2Gb RAM, GiGE interfaces. It's mostly idling.
Ah, yes, "mostly". Rather like drowning in that river of "average" depth less than 1 meter, except when you step into the hole that is 10 meters deep.
Its the "peak" handling capability that's the issue :-)
That is very true, but it's doing fine on that too, except when there are many inactive rsync processes. All the data to be sync'ed is in memory, so very little IO except for writing to the log, no swap in use. -- Per Jessen, Zürich (3.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2016 07:40 AM, Carlos E. R. wrote:
But... I see the advantage of xinetd when the target service is used sparsely. Once the job is finished, the rsyncd daemon exits and frees resources.
I'm not sure that makes sense. The Apache daemon listens for connections then spawns a copy of itself to deal with each incoming request. its real overhead is the CGI code, the RoR, the PHP or the Perl code. Linux is using shared code for the forks are efficient, it is the "execl"s to the CGI that cost. Rsyncd is not spawning any CGI. With Apache, as each process completes the code, the child is released and the parent process 'reaps' up the details. I can't see how a rsyncd "master" listener that spawns copies in the same was as Apache is any worse off. Your problem seems to be with the termination of the child processes.
But if it is used regularly, why not use the rsync daemon directly?
Another thing that I do not know, is what happens when there are two or more clients simultaneously. Do you get as many daemons running? In that case, you start to lose the advantage.
No more so that with Apache. -- 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
Anton Aylward wrote:
On 11/14/2016 07:40 AM, Carlos E. R. wrote:
But... I see the advantage of xinetd when the target service is used sparsely. Once the job is finished, the rsyncd daemon exits and frees resources.
I'm not sure that makes sense. The Apache daemon listens for connections then spawns a copy of itself
Depending on which mpm module you're using - the default is mpm_prefork, which does what it says :-)
I can't see how a rsyncd "master" listener that spawns copies in the same was as Apache is any worse off.
Your problem seems to be with the termination of the child processes.
Correct. -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2016 08:34 AM, Per Jessen wrote:
Anton Aylward wrote:
Your problem seems to be with the termination of the child processes.
Correct.
Perhaps we need to focus on that rather than on the 'top end', the ACL and the spawning. There are two ways that this can come about. a) the rsyncd is in fact not doing an exit but instead going into a listening loop b) the rysncd is in fact exiting but the 'zombie' is not being cleaned up. Which do you think it is? -- 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
Anton Aylward wrote:
On 11/14/2016 08:34 AM, Per Jessen wrote:
Anton Aylward wrote:
Your problem seems to be with the termination of the child processes.
Correct.
Perhaps we need to focus on that rather than on the 'top end', the ACL and the spawning.
There are two ways that this can come about.
a) the rsyncd is in fact not doing an exit but instead going into a listening loop
b) the rysncd is in fact exiting but the 'zombie' is not being cleaned up.
Which do you think it is?
Neither one - most of the apparently inactive processes have not yet dropped privileges, i.e. switched to the uid specified in the rsyncd module. That, according to rsync code, means the client has not yet chosen which module to use. When I strace such a process, all I see a sequence of select() with 60s timeout. It times out, then starts again. The question is why? -- Per Jessen, Zürich (3.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 16:21, Per Jessen wrote:
Neither one - most of the apparently inactive processes have not yet dropped privileges, i.e. switched to the uid specified in the rsyncd module. That, according to rsync code, means the client has not yet chosen which module to use. When I strace such a process, all I see a sequence of select() with 60s timeout. It times out, then starts again. The question is why?
It may be worth upping the verbosity of rsync as well as just looking at system calls. Also how much control do you have over the clients? Can you increase logging on them as well? What version are they and what protocol version is rsync using? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On 2016-11-14 16:21, Per Jessen wrote:
Neither one - most of the apparently inactive processes have not yet dropped privileges, i.e. switched to the uid specified in the rsyncd module. That, according to rsync code, means the client has not yet chosen which module to use. When I strace such a process, all I see a sequence of select() with 60s timeout. It times out, then starts again. The question is why?
It may be worth upping the verbosity of rsync as well as just looking at system calls.
I think I did try that, but I'm not sure it really gave much more info. I'll check it again.
Also how much control do you have over the clients?
None. They're just people from around the world using the rsync mirror. -- Per Jessen, Zürich (3.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 11/14/2016 02:17 AM, Per Jessen wrote:
[...] Running rsyncd with xinetd allows the system to do a lot more work.
Do you mean 'requires', as in 'do work that alternatives might not require and so places a greater load on the system" or do you mean "offers more options and flexibility" ??
xinetd has a higher listen backlog than rsyncd (3.0.7), that's all.
Afaict, xinetd is not part of the problem. xinetd just forks rsyncd for every new connection, and I would expect rsyncd to deny clients matching my "hosts deny" setting from rsyncd.conf.
I'm leaning to the belief that Xinetd *is* the problem becuase it is Xinetd that sees the connection information and should be handling the allow/deny, and that the relevant information is lost by the time rsyncd gets the connection.
Yes, that is possible, but the main issue is one of apparently inactive clients just hanging around clogging up the system. -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/14/2016 07:44 AM, Per Jessen wrote:
Anton Aylward wrote:
On 11/14/2016 02:17 AM, Per Jessen wrote:
[...] Running rsyncd with xinetd allows the system to do a lot more work.
Do you mean 'requires', as in 'do work that alternatives might not require and so places a greater load on the system" or do you mean "offers more options and flexibility" ??
xinetd has a higher listen backlog than rsyncd (3.0.7), that's all.
By "backlog" I presume you mean connection requests that have not yet spawned a server to deal with the it".
[...]
Yes, that is possible, but the main issue is one of apparently inactive clients just hanging around clogging up the system.
Are these clients that have completed the job? Hmm. I take it that you don't really mean 'clients', but instances of the spawned rsyncd. To me, 'clients' are the other end of the connection, the requesters not the servitors. -- 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
Anton Aylward wrote:
On 11/14/2016 07:44 AM, Per Jessen wrote:
Anton Aylward wrote:
On 11/14/2016 02:17 AM, Per Jessen wrote:
[...] Running rsyncd with xinetd allows the system to do a lot more work.
Do you mean 'requires', as in 'do work that alternatives might not require and so places a greater load on the system" or do you mean "offers more options and flexibility" ??
xinetd has a higher listen backlog than rsyncd (3.0.7), that's all.
By "backlog" I presume you mean connection requests that have not yet spawned a server to deal with the it".
It's the "backlog" parameter of the listen() call, see "man listen": "The backlog argument defines the maximum length to which the queue of pending connections".
[...]
Yes, that is possible, but the main issue is one of apparently inactive clients just hanging around clogging up the system.
Are these clients that have completed the job?
No, they look like they never get started. I've straced a few and they run a select() with a 60s timeout, it times out a number of times and then eventually something happens and the process exist. I've seen processes in this state for 15mins and 30mins and longer.
Hmm. I take it that you don't really mean 'clients', but instances of the spawned rsyncd. To me, 'clients' are the other end of the connection, the requesters not the servitors.
Well, the server process is active just waiting for client side to do something. -- Per Jessen, Zürich (3.7°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
Per Jessen wrote:
[...]
Yes, that is possible, but the main issue is one of apparently inactive clients just hanging around clogging up the system.
Are these clients that have completed the job?
No, they look like they never get started. I've straced a few and they run a select() with a 60s timeout, it times out a number of times and then eventually something happens and the process exist.
s/exist/exits/. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I have an rsyncd service for mirroring sanesecurity data. Generally it works very well, but occasionally the rsyncd server will get hung up with many rsyncd processes just waiting on (apparently) inactive clients. This can go on for minutes, possibly hours. I'm running rsyncd via xinetd. The 'timeout' parameter for rsyncd.conf doesn't seem to take effect. I have now taken to automatically killing any rsyncd process running for more than 90seconds, which has improved things tremendously. Also, rsyncd seems to ignore my "hosts deny" setting - I tried refusing access to a couple of the most frequently hanging clients, but afaict, rsyncd just ignores "hosts deny".
I'm happy to post complete configs, but before I clog up the list with that, somebody might recognise the scenario above?
Here is an example of what it looks like: # ps -C rsyncd -o pid=,etime= 8777 30:48 11751 15:00 12024 13:20 12331 11:08 12817 08:19 13284 05:07 13868 02:12 14153 00:42 14241 00:18 14389 00:02 14393 00:01 14397 00:01 14398 00:01 14399 00:01 Normally, those 6 processes with longer run-times will eventually terminate by themselves, but not always. Sometimes they're stuck for much longer and the number grows, ending up choking the server/rsync process. http://sanesec.jessen.ch Above, look at the "Requests" column - typically about 100K/day, but some days only 4-5K or less. I have just now tried going back to running just rsyncd (instead of xinetd), just to see if xinetd might be causing some sort of problem after all. It didn't change anything - now after writing this and answering the phone: # ps -C rsyncd -o pid=,etime= 8777 41:58 13868 13:22 14153 11:52 14241 11:28 14939 08:52 14984 08:34 15992 05:06 16201 04:54 16511 04:33 16883 04:09 17255 03:42 17658 03:10 17891 02:50 18041 02:34 18044 02:34 Now switching back to xinetd. -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Dave Howorth -
Lew Wolfgang -
Per Jessen -
Roger Price