How do I find out why a RSync task is failing?

[Tony Self]

I have a RSync that is set up to copy files from my UK server to my Thai server. Usually this proceeds without a problem, but occasionally the task fails mid transfer probably due to a temporary connectivity issue.

When I try to manually restart the task it continually fails, even though I am connected to the UK server remotely so there obviously isn't a connectivity issue at the time.

Where can I find out why the task continues to fail?

 

[sretalla]

Is the rsync job working with IP addresses or DNS names?

 

[Tony Self]

The push rsync job on my UK server is using a DNS name. However the receiving service on my Thai server uses an IP address to filter the incoming connection.
As I said generally the job works without a problem, but there are the odd occasions where a session gets interrupted that it is difficult to restart the job. All I seem to get is a failed alert. What I am after is more detail as to why the restarts are failing so I can resolve the problem and get the job restarted more quickly.
As it happens the job has now restarted and completed. But I do want to know why I couldn't restart the job earlier. There must be some log file somewhere which will give me a bit more information. Or perhaps I need to add an additional option to the job so it will give a more verbose reason for failing rather than a simple "FAILED"

Regards

Tony Self

 

[sretalla]

I was anticipating a potential problem with DNS following an IP cut... I agree that's not great error reporting, so hard to say what's going on.

Have a look for recently changed files under /var/log

 

[Tony Self]

Having posted my earlier reply, but then having thought further on your question, I think I have realised what the problem is.
As I said the Push Rsync job uses a DNS name, mainly because I have a dynamic IP address on my Thai server. If the Rsync connection goes down because of a power cut at my Thai location (a not uncommon event) then my ISP will assign a new IP address which will take a little while for NOIP.com to propagate, hence the initial failures to re-establish a connection because it won't be using the newly assigned IP address.

I mustn't put off getting a fixed IP address any longer.

Regards

Tony Self