Same here.
There isn't a pattern I could deduce.

The only weird thing that happened was that the root.root permissions are on the host where the file was put. So I didn't suspect csync, but the application doing the writing.


On 17-07-17 15:01, Aristedes Maniatis wrote:
After years of reliable service, csync2 2.0 did exactly that for me just last 
week. One file suddenly owned by root.

On 17/7/17 10:32PM, Kevin Cackler wrote:
Funnily enough, we are also experiencing this issue with the root owned files. 
Randomly, and without any definable pattern, so far as we can tell, we'll get a 
file that suddenly is owned by root:root with rw permissions and we have to go 
in and correct the permissions. So far we haven't been able to nail down the 
cause of this.

Mark Hodge wrote:

I've recently setup a csync cluster between 3 nodes and although the
ring model works ok, it obviously fails when the middle server (node
2) is offline. Therefore I've been trying to get a working config that
is something like this:

node1 => node2 + node3
node2 => node1 + node3
node3 => node1 + node2

So at least if node2 is offline, node1+node3 are still syncing.

Is this the best way to achieve this? using "master (slave)" pairs?

I ended up putting csync on all nodes in a cron every minute (lsync
would crash occasionally) when csync returned errors.

I got lots of "Database is busy, sleeping a sec" errors, which I
presumed was because csync was running at the same time on each node
and causing db locks. So I staggered them, at 0, 20 and 40 sec in the
minute which got rid of the "busy" errors.

However, occasionally I will get random files appear one one or more
nodes owned by "root" with perms "rw" only for owner. This means
standard users cannot access these files. I suspect that csync is
somehow failing to set uid/gid/perms after the copy.

How can this happen?


Csync2 mailing list

Csync2 mailing list

Csync2 mailing list

Csync2 mailing list

Reply via email to