Bug 958062 - [rfe ] logging: date mismatch in glusterfs logging and system "date"
Summary: [rfe ] logging: date mismatch in glusterfs logging and system "date"
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterfs
Version: 2.1
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: Kaleb KEITHLEY
QA Contact: Vijay Avuthu
URL:
Whiteboard: rebase
Depends On: 1563334
Blocks: 1121626
TreeView+ depends on / blocked
 
Reported: 2013-04-30 09:49 UTC by Saurabh
Modified: 2018-12-05 15:57 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1121626 (view as bug list)
Environment:
Last Closed: 2018-11-14 03:26:04 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1531930 0 unspecified CLOSED [Doc RFE] Document how to set cluster.localtime-logging volume option 2021-02-22 00:41:40 UTC

Internal Links: 1531930

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


Note You need to log in before you can comment on or make changes to this bug.