Bug 958062

Summary:	[rfe ] logging: date mismatch in glusterfs logging and system "date"
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Saurabh <saujain>
Component:	glusterfs	Assignee:	Kaleb KEITHLEY <kkeithle>
Status:	CLOSED WONTFIX	QA Contact:	Vijay Avuthu <vavuthu>
Severity:	high	Docs Contact:
Priority:	low
Version:	2.1	CC:	amukherj, atumball, bkunal, cfeller, dblack, kcleveng, kkeithle, lmohanty, mohit_anchlia, nchilaka, rallan, rcyriac, rhinduja, rhs-bugs, sankarshan, sdharane, sheggodu, tnagata, vavuthu, vbellur, vdas
Target Milestone:	---	Keywords:	FutureFeature, ZStream
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	rebase
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1121626 (view as bug list)		Environment:
Last Closed:	2018-11-14 03:26:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1563334
Bug Blocks:	1121626

Description Saurabh 2013-04-30 09:49:14 UTC

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:

Comment 2 Amar Tumballi 2013-05-03 05:51:54 UTC

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.

Comment 5 Chad Feller 2013-11-08 21:47:36 UTC

This is an issue in GlusterFS 3.4.1 as well. If not a bug, please consider as an RFE?

Comment 6 Chad Feller 2013-11-08 21:48:36 UTC

(or should I open a separate bug on this for GlusterFS, as this is technically RHS?)

Comment 7 Kaleb KEITHLEY 2013-11-08 22:20:14 UTC

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'

Comment 8 Dustin Black 2014-06-03 23:58:22 UTC

Are we going to NOTABUG this one, or are we considering a change to enable glusterfs logging in local/preferred time zones?

Comment 10 Atin Mukherjee 2016-01-08 06:21:38 UTC

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?

Comment 19 Kaleb KEITHLEY 2018-03-26 14:20:18 UTC

what is the question?

Comment 31 Vijay Avuthu 2018-04-06 13:30:00 UTC

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.

Comment 32 Atin Mukherjee 2018-04-06 14:03:01 UTC

(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.

Comment 33 Vijay Avuthu 2018-04-09 13:45:15 UTC

(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 )

Comment 37 Amar Tumballi 2018-10-30 09:11:03 UTC

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).