Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gluster-block: add logrotate support #163

Merged
merged 4 commits into from
Apr 3, 2019
Merged

Conversation

lxbsz
Copy link
Collaborator

@lxbsz lxbsz commented Nov 19, 2018

Fixes: issue #164

Signed-off-by: Xiubo Li [email protected]

@ghost ghost assigned lxbsz Nov 19, 2018
@ghost ghost added the in progress label Nov 19, 2018
Copy link
Contributor

@pkalever pkalever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rest looks good to me @lxbsz

@lxbsz lxbsz force-pushed the logrotate branch 2 times, most recently from 538a026 to 5771283 Compare November 30, 2018 06:38
@pkalever
Copy link
Contributor

@lxbsz can you please rebase this on current ?

@lxbsz
Copy link
Collaborator Author

lxbsz commented Mar 20, 2019

@lxbsz can you please rebase this on current ?

Sure, will do it later.
Thanks.

@lxbsz lxbsz force-pushed the logrotate branch 2 times, most recently from af0b9af to dd84e7d Compare March 24, 2019 00:48
@lxbsz
Copy link
Collaborator Author

lxbsz commented Mar 24, 2019

@pkalever @amarts
Updated it.
Thanks.

@lxbsz
Copy link
Collaborator Author

lxbsz commented Mar 28, 2019

@pkalever This has been already fixed, please see:

dd84e7d

Thanks.

@lxbsz
Copy link
Collaborator Author

lxbsz commented Mar 29, 2019

@pkalever
Fix them all, please review.
Thanks.

Copy link
Contributor

@pkalever pkalever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lxbsz we cannot watch on /etc/sysconfig. We need to create a new config dir under like /etc/sysconfig/gluster-block/ and then move the conf file under it. Then we can watch on /etc/sysconfig/gluster-block/ directory

HTH

@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 2, 2019

@lxbsz we cannot watch on /etc/sysconfig. We need to create a new config dir under like /etc/sysconfig/gluster-block/ and then move the conf file under it. Then we can watch on /etc/sysconfig/gluster-block/ directory

@pkalever
As we discussed days ago, it is watching the /etc/sysconfig/ directory and will the filter out whether the gluster-blockd config file is changed.

So please review.
Thanks.

@pkalever
Copy link
Contributor

pkalever commented Apr 2, 2019

@lxbsz we cannot watch on /etc/sysconfig. We need to create a new config dir under like /etc/sysconfig/gluster-block/ and then move the conf file under it. Then we can watch on /etc/sysconfig/gluster-block/ directory

@pkalever
As we discussed days ago, it is watching the /etc/sysconfig/ directory and will the filter out whether the gluster-blockd config file is changed.

So please review.

@lxbsz This was in my list yesterday, got skipped coz I worked on something else.
I will provide the review today.

Thanks!

Copy link
Contributor

@pkalever pkalever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lxbsz have left few review suggestions, please take a look. Thanks!

@pkalever
Copy link
Contributor

pkalever commented Apr 2, 2019

@lxbsz also can this series accommodate leak reported at #183

@lxbsz lxbsz force-pushed the logrotate branch 2 times, most recently from 8ee872d to cbe7341 Compare April 3, 2019 04:07
@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

@pkalever Updated it. Thanks.

@lxbsz lxbsz force-pushed the logrotate branch 2 times, most recently from 9bc7167 to fb0f7ac Compare April 3, 2019 04:56
@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

@lxbsz also can this series accommodate leak reported at #183

There is no any memory leakage here, I updated the issue#183.

Thanks.

Copy link
Contributor

@pkalever pkalever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lxbsz this series looks much simplified.

Do you want to send below patches in a separate PR ?

  • config: logDir add dyn support
  • logrotate: update the logdir path whenever it changes
  • dyn-cfg: skip resetting options if they match with current

Thanks!

@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

@lxbsz this series looks much simplified.

Do you want to send below patches in a separate PR ?

  • config: logDir add dyn support
  • logrotate: update the logdir path whenever it changes
  • dyn-cfg: skip resetting options if they match with current

Yeah, let's add this after we resolved the -glfs.log issue. Or the logDir dyn make no sense.

Thanks!

@pkalever
Copy link
Contributor

pkalever commented Apr 3, 2019

@lxbsz this series looks much simplified.
Do you want to send below patches in a separate PR ?

  • config: logDir add dyn support
  • logrotate: update the logdir path whenever it changes
  • dyn-cfg: skip resetting options if they match with current

Yeah, let's add this after we resolved the -glfs.log issue. Or the logDir dyn make no sense.

Yeah, this is one simple thing to do.
We can fetch the all glfs objects from LRU cache and set:

for each glfs in lruCaheList:
  ret = glfs_set_logging(glfs, ${dynamic-logDir}/gluster-block-gfapi.log", 7);

@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

@lxbsz this series looks much simplified.
Do you want to send below patches in a separate PR ?

  • config: logDir add dyn support
  • logrotate: update the logdir path whenever it changes
  • dyn-cfg: skip resetting options if they match with current

Yeah, let's add this after we resolved the -glfs.log issue. Or the logDir dyn make no sense.

Yeah, this is one simple thing to do.
We can fetch the all glfs objects from LRU cache and set:

for each glfs in lruCaheList:
  ret = glfs_set_logging(glfs, ${dynamic-logDir}/gluster-block-gfapi.log", 7);

As I remembered months ago, after the volume is inited by glfs_init, there will be a problem with this.
Not very sure, I need much more test.

Thanks.

@pkalever
Copy link
Contributor

pkalever commented Apr 3, 2019

As I remembered months ago, after the volume is inited by glfs_init, there will be a problem with this.
Not very sure, I need much more test.

I tested this locally (with very few changes to glfs-tests.c ) and it works for me.
If yo notice anything specific, you should file it.

Thanks!

@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

As I remembered months ago, after the volume is inited by glfs_init, there will be a problem with this.
Not very sure, I need much more test.

I tested this locally (with very few changes to glfs-tests.c ) and it works for me.
If yo notice anything specific, you should file it.

Okay, cool.
Let's do this in another PR and also we need to fix this in tcmu-runner at the same.

BRs

Thanks!

@pkalever
Copy link
Contributor

pkalever commented Apr 3, 2019

I tested this locally (with very few changes to glfs-tests.c ) and it works for me.
If yo notice anything specific, you should file it.

Okay, cool.
Let's do this in another PR and also we need to fix this in tcmu-runner at the same.

  • I'm okay moving this part to next PR. Can you just raise a issue for this, so that we don't miss out ?
  • Please respin this series with agreed changes

Thanks!

@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

I tested this locally (with very few changes to glfs-tests.c ) and it works for me.
If yo notice anything specific, you should file it.

Okay, cool.
Let's do this in another PR and also we need to fix this in tcmu-runner at the same.

  • I'm okay moving this part to next PR. Can you just raise a issue for this, so that we don't miss out ?
  • Please respin this series with agreed changes

Sure. #199

@pkalever
Copy link
Contributor

pkalever commented Apr 3, 2019

Sample output:
[root@Fedora-Server gluster-block]# ls -l /var/log/gluster-block
total 774728
0001-logs-remove-n-in-LOG-usage.patch.txt

-rw-r--r--. 1 root root 9356 Mar 29 22:36 cmd_history.log
-rw-r--r--. 1 root root 1356 Mar 29 19:00 gluster-block-cli.log
-rw-r--r--. 1 root root 9298 Mar 29 22:36 gluster-block-configshell.log
-rw-r--r--. 1 root root 1928 Apr 3 16:49 gluster-blockd.log
-rw-r--r--. 1 root root 737029075 Apr 3 16:22 gluster-blockd.log.1
-rw-r--r--. 1 root root 56215936 Apr 3 16:18 gluster-blockd.log.2.gz
-rw-------. 1 root root 39118 Mar 29 22:36 gluster-block-gfapi.log
[root@Fedora-Server gluster-block]#

Reviewed & Tested-by: Prasanna Kumar Kalever <[email protected]>

@lxbsz please update the tags.

Also can you consider this patch to be attached as part of this PR:
0001-logs-remove-n-in-LOG-usage.patch.txt

Without this patch the dyn-config logs looks quite clumsy for me.

Thanks!

lxbsz and others added 4 commits April 3, 2019 20:22
Signed-off-by: Xiubo Li <[email protected]>
Reviewed-by: Prasanna Kumar Kalever <[email protected]>
Tested-by: Prasanna Kumar Kalever <[email protected]>
Editors (such as vim, nano ..) follow different approaches to save conf file.
The two commonly followed techniques are to overwrite the existing file, or to
write to a new file (.swp, .tmp ..) and move it to actual file name later. In
the later case, the inotify fails, because the file it's been intended to watch
no longer exists, as the new file is a different file with just a same name.

To handle both the file save approaches mentioned above, it is better we watch
the directory and filter for MODIFY events.

Signed-off-by: Xiubo Li <[email protected]>
Reviewed-by: Prasanna Kumar Kalever <[email protected]>
Tested-by: Prasanna Kumar Kalever <[email protected]>
Signed-off-by: Xiubo Li <[email protected]>
Reviewed-by: Prasanna Kumar Kalever <[email protected]>
Tested-by: Prasanna Kumar Kalever <[email protected]>
Signed-off-by: Prasanna Kumar Kalever <[email protected]>
@lxbsz
Copy link
Collaborator Author

lxbsz commented Apr 3, 2019

Sample output:
[root@Fedora-Server gluster-block]# ls -l /var/log/gluster-block
total 774728
0001-logs-remove-n-in-LOG-usage.patch.txt

-rw-r--r--. 1 root root 9356 Mar 29 22:36 cmd_history.log
-rw-r--r--. 1 root root 1356 Mar 29 19:00 gluster-block-cli.log
-rw-r--r--. 1 root root 9298 Mar 29 22:36 gluster-block-configshell.log
-rw-r--r--. 1 root root 1928 Apr 3 16:49 gluster-blockd.log
-rw-r--r--. 1 root root 737029075 Apr 3 16:22 gluster-blockd.log.1
-rw-r--r--. 1 root root 56215936 Apr 3 16:18 gluster-blockd.log.2.gz
-rw-------. 1 root root 39118 Mar 29 22:36 gluster-block-gfapi.log
[root@Fedora-Server gluster-block]#

Reviewed & Tested-by: Prasanna Kumar Kalever <[email protected]>

@lxbsz please update the tags.

Also can you consider this patch to be attached as part of this PR:
0001-logs-remove-n-in-LOG-usage.patch.txt

Without this patch the dyn-config logs looks quite clumsy for me.

Yeah, updated it.
Thanks.

Thanks!

@pkalever pkalever merged commit 5c5ebf0 into gluster:master Apr 3, 2019
@ghost ghost removed the in progress label Apr 3, 2019
@pkalever
Copy link
Contributor

pkalever commented Apr 3, 2019

@lxbsz Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants