LinuxQuestions.org - rsync works in one direction, but not the other

- Linux - Desktop (https://www.linuxquestions.org/questions/linux-desktop-74/)

- - rsync works in one direction, but not the other (https://www.linuxquestions.org/questions/linux-desktop-74/rsync-works-in-one-direction-but-not-the-other-573711/)

rsync works in one direction, but not the other

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.

Other possibilities?
Help?

jackn

well, it would seem rsync daemon isn't running on the desktop

check your installation documentation.

try looking for an rsync script in /etc/init.d
and start it manually as root

probably your firewall setting, try to turn it off 1st?

Right on the money, bigearsbilly...

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.

jackn

wow I was right ;)

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.

Yes, indeed, it's the setup of rsync.

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.

jackn

no problem!
that's what we're all here for

Update, and, hopefully setting things straight

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.

Thanks for the help and attention.

jackn