|
To confirm: Joe's explanation, uncomfortable as it, looks to be the correct one. When the servers were powered off and restarted (so the gluster processes /had/ to be restarted, the new ones started up and used the correct time format.
The 'problem' clients were the ones which were running the updated version; when all the clients were forced to restart the glusterfs; they all appear to be running with the UTC time (tho hard to tell since the number of logged incidents has fallen dramatically).
There is a repeating entry in all the server logs tho:
1001 $ tail -3 /var/log/glusterfs/etc-glusterfs-glusterd.vol.log [2013-12-11 18:26:41.824180] E [socket.c:2788:socket_connect] 0-management: connection attempt failed (Connection refused) [2013-12-11 18:26:44.825089] E [socket.c:2788:socket_connect] 0-management: connection attempt failed (Connection refused) [2013-12-11 18:26:47.825952] E [socket.c:2788:socket_connect] 0-management: connection attempt failed (Connection refused)
Is there a way to detect which client(s) this is coming from?
On Tuesday, December 10, 2013 11:23:11 AM Joe Julian wrote: > If I were to hazard a guess, since the timestamp is not configurable and > *is* UTC in 3.4, it would seem that any server that's logging in local time > must not be running 3.4. Sure, it's installed, but the application hasn't > been restarted since it was installed. That's the only thing I can think of > that would allow that behavior.
--- Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine [m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487 415 South Circle View Dr, Irvine, CA, 92697 [shipping] MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps) ---
|
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
