Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've set up rsync between two connected boxes, but it only works in one direction between the two boxes.
rsync is set up to be started by xinetd when a call from a client reaches xinetd.
When I mirror from the laptop to the desktop, it works like a charm.
When I try to mirror from the desktop to the laptop, no dice.
This difference between the two directions occurs at the very beginning of the protocol, when trying to call the rsync daemon.
In the former, succesful case, initiation gives:
Code:
desktop$ rsync rsync://laptop_name
module Module used to backup /files here, on laptop, to files/backup on desktop
namely, the name of the module and the comment on it. I can also go ahead and browse or mirror the whole directory in the module.
In the latter case, on the other hand:
Code:
laptop$ rsync rsync://desktop_name
simply gives rise to a blinking cursor. It just hangs there for as long as I let it, and nothing happens.
I've tried to look up the rsync.log on the daemon (on the desktop), but it has no trace of the call.
Likewise, the last line in /var/log/syslog (where xinetd logs to) is:
Code:
Jul 31 19:01:26 desktop_name xinetd[10363]: Started working: 0 available services
which means that xinetd is on, but unaware of the call from the laptop, as the rsync call occurred later...
Finally, here's another bit of data:
Code:
desktop$ rsync rsync://backup@localhost
rsync: failed to connect to localhost: Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(104) [receiver=2.6.9]
So, the desktop won't rsync to itself.
The laptop, by contrast, will.
This suggests to me that port 873 isn't open on the desktop.
Two tests would be to try and rsync through ssh (port 22), but I don't know how to yet, or to open the port, which I don't know how to do yet either.
Here's the error message I would get when I simply tried to connect:
Code:
$ rsync rsync://desktop_name
rsync: failed to connect to desktop_name: Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(104) [receiver=2.6.9]
Having run
Code:
sudo /etc/init.d/rsync start
on the desktop, I now get:
Code:
$ rsync rsync://desktop_name
module_name Module set up to back up /files here, on desktop, to laptop.
$
This is wonderful, because this narrows down things quite a bit. It is clearly not a port issue, as when rsync is made to run, it communicates very well.
So, I could manually start rsync every time I wanted to run it.
Yet, it would be nicer to automate this (it's a backup task).
The rsync daemon is usually run through a super-server (inetd, xinetd) so as to avoid having a whole lot of servers listening to calls. I could simply have rsync permanently on, but it would be nice to get it to run upon calls.
In my case, I have set it up to be started by xinetd, which has worked very well on the laptop. It seems to be the default on Ubuntu, the distro I'm running.
So why doesn't the desktop's xinetd respond to calls, whereas the laptop's does?!
The xinetd daemon is permanently on:
Code:
$ ps aux | grep inetd
root 8942 0.0 0.1 2348 860 ? Ss 07:48 0:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive
And the inetd one isn't.
rsync figures in /etc/services with the 873 port and the tcp protocol assigned.
I have also set up an xinetd.d/rsync file, to have xinetd run rsync:
Code:
xinetd.d/rsync:
service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
log_on_failure += USERID
}
I have verified the path to rsync.
In short, I am not aware of any differences in the setup between the laptop and the desktop, yet the desktop's daemon won't respond to calls, whereas the laptop's will.
It looks like either an xinetd issue, or sth to do with its starting rsync. rsync itself clearly works just fine.
Another thing I could do is use inetd, instead of xinetd, to start rsync. This would be a workaround I could live with very well. I'm just not fully sure about how to go about it (launch inetd through .bashrc?), and I'd rather use what the distro uses by default, which might prevent other conflicts in the future. What do you think? Also, it would be nice to figure out why the desktop's xinetd doesn't respond to calls.
Thank you very much, kstan and bigearsbilly, for your ideas and information.
to be honest I haven't had or heard of any sort of problem ever with (x)inetd
not working. though generally i think I use inetd. (I just go with default
setup).
I would think it better first to check if the startup scripts are
1. enabled (check your sysadmin guide for your distro)
2. being called and operating correctly,
I would think this more likely.
It's not unknowm for different machines to configure differently in my experience.
maybe they feel a laptop is more likely to need rsync than a desktop so it's disabled on the desktop enabled if a laptop? Possible.
In Ubuntu, at least, you need to set RSYNC_ENABLE (in /etc/defaults/rsync) to True...
I set it to 'true'...
Since one machine, with the same setup apparently, was OK, and the other not, my next move was to run diff on each of the config files, which would have come up with the culprit...
But then I finally noticed the error message upon shutdown, telling me the variable above could only be set up to True or False...
Even then it took a while for it to dawn on me that it was the missing capital letter. Gotta comply with them Unix conventions...
Strangest of all, the laptop, on which rsync worked fine, was set to 'xinetd'. Yet, it worked... Go figure.
Well, all's well now.
I've learnt quite a bit by sorting this out.
Thank you, Billy, for the ideas and the listening.
First off, I now have rsync regulary working in both directions without fail.
As to my previous posts in this thread, I was wrong, I don't know why, but the RSYNC_ENABLE variable should be set to 'true' and not 'True'. I'm sorry about that.
More importantly, my problems with rsync working only unidirectionally kept popping up, and I had no idea why.
One clue was that two other protocols I was using, namely nfs and ssh also worked only intermittently. Just like rsync, and in unison with it, they would either work both ways or, erratically, only unidirectionally.
Furthermore, while the three protocols above only worked intermittently, I could always ping either machine all the time, and I could always surf the net. Again, I emphasize, pinging was on all the time and so was internet access, whereas the three protocols worked intermittently.
Since I thought pinging and internet access meant a working network, I did not think I had a networking problem.
One day, however, for another reason, I followed advice on how to have Network Manager run the network. Basically, I had to stop NM, restart /etc/init.d/networking, and restart NM.
Ever since then, everything works all the time.
I think this shows it was a networking problem, but I don't know enough to figure out what could stop protocols, but not net access or pinging.
It's a 'solution' without understanding, but I'm happy to have things working, and others may understand better what's going on here.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.