On Tuesday, December 10, 2013 10:42:28 AM
Vijay Bellur wrote:
> On 12/10/2013 10:14 AM, harry mangalam
wrote:
> > Admittedly I should search the
source, but I wonder if anyone knows this
> > offhand.
> >
> > Background: of our 84 ROCKS (6.1)
-provisioned compute nodes, 4 have
> > picked up an 'advanced date' in the
/var/log/glusterfs/gl.log file -
> > that date string is running about
5-6 hours ahead of the system date and
> > all the Gluster servers (which are
identical and correct). The time
> > advancement does not appear to be
identical tho it's hard to tell since
> > it only shows on errors and those
update irregularly.
>
> The timestamps in the log file are by
default in UTC. That could
> possibly explain why the timestamps look
advanced in the log file.
that seems to make sense. The advanced time
on the 4 problems nodes looks to be the correct UTC time, but
the others are using /local time/ in their logs, for some
reason. And localtime nodes are the ones NOT having problems.
...??!
However, this looks to be more of a ROCKS /
config problem than a general gluster problem at this point. All
the nodes have the md5-identical /etc/localtime, but they seem
to be behaving differently as to the logging.
Thanks for the pointer.
hjm
> > All the clients are the same
version and all the servers are the same
> > (gluster v 3.4.0-8.el6.x86_64
> >
> > This would not be of interest
except that those 4 clients are losing
> > files, unable to reliably do IO,
etc on the gluster fs. They don't
> > appear to be having problems with
NFS mounts, nor with a Fraunhofer FS
> > that is also mounted on each node,
>
> Do you observe anything in the client
log files of these machines that
> indicate I/O problems?
Yes.
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.