Description of problem: gluster logs mention some other time, a mismatch from "date" command Version-Release number of selected component (if applicable): glusterfs-3.4.0.1rhs-1.el6rhs.x86_64 How reproducible: always(Have seen the on other machines also) Steps to Reproduce: 1. check logging messages in /var/log/glusterfs dir 2. 3. Actual results: [2013-04-30 02:57:10.721125] E [glusterd-utils.c:5112:glusterd_is_path_in_use] 0-management: /rhs/brick1/vol0 or a prefix of it is already part of a volume [2013-04-30 02:57:10.721159] E [glusterd-syncop.c:713:gd_stage_op_phase] 0-management: Staging of operation 'Volume Create' failed on localhost : /rhs/brick1/vol0 or a prefix of it is already part of a volume (END) where as "date" shows [root@rhs-goldman1 ~]# date Tue Apr 30 08:27:39 IST 2013 Expected results: the time should match Additional info:
Good to have fix for Big Bend. Issue here is, glusterfs logs every log with timestamp aligned to UTC, and not timezone. But its preferable to have it as configurable to choose timezone.
This is an issue in GlusterFS 3.4.1 as well. If not a bug, please consider as an RFE?
(or should I open a separate bug on this for GlusterFS, as this is technically RHS?)
timestamps the log are UTC (as any good appliance the time should be set to UTC, and the logs too. This is what you'll find on, e.g. NetApp and EMC storage appliances.) If want date to show times that "match" the gluster logs, use 'export TZ=UTC && date' or 'setenv TZ UTC && date'
Are we going to NOTABUG this one, or are we considering a change to enable glusterfs logging in local/preferred time zones?
If the servers are across different geography following a universal time is much safer option compared to following local times as in that case debugging logs can be a night mare. Kaleb also provided a workaround in #c7. Based on that can we take a decision and close this bug?
what is the question?
Update: ======== Re-verified with build: glusterfs-server-3.12.2-7.el7rhgs.x86_64 Logs which are changed to local time zone after enabling : glusterd, rebalance, cmd_history, samba Logs which are not changed : geo-rep, cli.log, ganesha Logs which needed reloaded ( enabling option won't be affect till service/pid/xlator is reloaded ) : glustershd.log and brick logs > Is above behavior is by design ? > From the usabilty/debugging point of view, it creates more confusion if we don't maintain consistency in all log files. > As soon as we enable option, localtime-logging should take effect without reloaded/restart daemon/pid/xlator.
(In reply to Vijay Avuthu from comment #31) > Update: > ======== > > Re-verified with build: glusterfs-server-3.12.2-7.el7rhgs.x86_64 > > Logs which are changed to local time zone after enabling : glusterd, > rebalance, cmd_history, samba Are you absolutely sure this is true for samba? As per my understanding the daemons which glusterd doesn't maintain (which includes samba and nfs-ganesha) would not have these changes reflected. > > Logs which are not changed : geo-rep, cli.log, ganesha I don't think we can change the cli.log to follow local time until and unless we pass an explicit parameter to it or read the local timezone value from /var/lib/glusterd which is actually quite ugly. Need to think more how this can be implemented. Regarding geo-rep, I need to talk to Kotresh on how to achieve it. I'm keeping the needinfo intact for now. > > Logs which needed reloaded ( enabling option won't be affect till > service/pid/xlator is reloaded ) : glustershd.log and brick logs That's expected. This needs a service restart as this option is passed as part of spawning these processes. > > > > Is above behavior is by design ? > > From the usabilty/debugging point of view, it creates more confusion if we don't maintain consistency in all log files. > > As soon as we enable option, localtime-logging should take effect without reloaded/restart daemon/pid/xlator.
(In reply to Atin Mukherjee from comment #32) > (In reply to Vijay Avuthu from comment #31) > > Update: > > ======== > > > > Re-verified with build: glusterfs-server-3.12.2-7.el7rhgs.x86_64 > > > > Logs which are changed to local time zone after enabling : glusterd, > > rebalance, cmd_history, samba > > Are you absolutely sure this is true for samba? As per my understanding the > daemons which glusterd doesn't maintain (which includes samba and > nfs-ganesha) would not have these changes reflected. > For Samba, local time zone is not reflecting. ( As per previous comment, its expected samba and nfs-ganesha is out of scope )
We are not planning to fix it for samba and nfs-ganesha logs. For now the logs are using localtime with the option. Bipin, as we are focusing on more severe issues, and more on OCS, we are not planning to work on this cosmetic change of volume info not having the option for now. Let me know if that is enough to consider this as CURRENTRELEASE (as per comment#31).