a) Description of problem: The system date is different from glusterfs log dates. There exists a bugzilla for RHS2.1, but none for RHS3.0. b) Version-Release number of selected component (if applicable): glusterfs-libs-3.6.0.28-1.el6rhs.x86_64 glusterfs-cli-3.6.0.28-1.el6rhs.x86_64 c) How reproducible: Always d) Steps to Reproduce: Check the output of 'date' command and compare it with the date of the logs in /var/log/glusterfs/ # date Mon Mar 2 16:10:30 IST 2015 # less /var/log/glusterfs/etc-glusterfs-glusterd.vol.log ~~~ [2015-02-26 14:45:16.479661] I [MSGID: 100030] [glusterfsd.c:1998:main] 0-glusterd: Started running glusterd version 3.6.0.28 (args: glusterd --xlator-option *.upgrade=on -N) [2015-02-26 14:45:16.536017] I [graph.c:269:gf_add_cmdline_options] 0-management: adding option 'upgrade' for volume 'management' with value 'on' [2015-02-26 14:45:16.536308] I [glusterd.c:1188:init] 0-management: Maximum allowed open file descriptors set to 65536 ~~~ e) Actual results: The gluster logs are reporting in a different timezone compared to the system time. f) Expected results: The gluster logs should be reporting in the system date/time. g) Additional info: This is reported for RHS2.1 as well. https://bugzilla.redhat.com/show_bug.cgi?id=958062 https://bugzilla.redhat.com/show_bug.cgi?id=1121626
The intention of keeping the log timing following UTC is to ensure the servers across different geography stick to a specific time zone w.r.t logging. Following system date would be really difficult to debug any issue where multiple nodes across different geography is involved. IMHO, we should stick to this format and shouldn't change it to machine specific time. Considering that can we close this case?
Sure, Atin. You can close the BZ. Thanks, Bipin
Based on comment 5 & 6, closing this BZ.