I assume the logfile rotation would be happening on the system being rsync'd FROM.

You'll have to check how rsync does its directory comparison, but I think it does it once at the start of the sync. So if the rotation happens after that point, but before the copies are complete, then your latest log slice might be missed by the rsync.

But it's not "lost" -- it's just not rsync'd.

All you have to do is set up the Rotate's to happen every n minutes (60, 120, whatever...), and rsync in the middle of those intervals. In that case, unless you've accumulated more data in n/2 minutes than rsync can move, rsync isn't going to conflict with the rotation...

I want to rotate the rsynd server's log file.

When some rsync client boxes rsync its local dir to the rsynd server, rsynd server will log what files it received from the clientbox. And I want to analyze the rsyncd server's log file in an hour interval, then extract what files it received from the client boxes and do some process on these files.

So I want to rotate rsyncd server's log file by hourly, but I am afraid that I maybe rotate the server log file while the server is also updating the log file, when these two actions happen to the same log file at the same time, will be there something bad happen, like some logs will be lost?

Typically what you do when rotating log files is to rename the current log file - and leave it alone for a while. Many daemons open the log file once, and only close it when they are done. Renaming an open file is ok, the process is only using the handle, it doesn't care about the rename.

It may be that the main rsynd process needs to be send a SIGHUP - but you'll have to check that. Sometimes a daemon opens a log file, and then when it has to do work, it forks, giving its child an open file handle. Typically, on a SIGHUP the main daemon closes and reopens any handles. But if the main daemon doesn't keep open handles, there's no need.