-
Notifications
You must be signed in to change notification settings - Fork 148
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
config: add the logdir option dynamic reloading support #368
Conversation
libtcmu_config.c
Outdated
tcmu_warn("The logdir option is not supported by dynamic reloading for now!\n"); | ||
/* | ||
* Here we asume that users want to change the | ||
* log_dir_path without considering tha priority |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change "tha" to "the".
libtcmu_config.c
Outdated
tcmu_logdir_create(cfg->log_dir_path, true); | ||
ret = tcmu_create_file_output(tcmu_get_log_level(), TCMU_LOG_FILENAME, true); | ||
if (ret < 0) | ||
tcmu_err("create file output error \n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's change this to:
Could not change log path to %s.\n, new log dir path
I would say also report the error code, but create_file_output is a mess of -1 and -errno.
libtcmu_config.c
Outdated
* mentioned above. | ||
*/ | ||
tcmu_logdir_create(cfg->log_dir_path, true); | ||
ret = tcmu_create_file_output(tcmu_get_log_level(), TCMU_LOG_FILENAME, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
80 char cols.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a general issue here is that we do
tcmu_destroy_log()
then
tcmu_destroy_config()
so if during the log resources are freed and destroyed then someone does a update, this would leak and access freed resources.
I think we need to change the ordering or add some new log function that handles checking if the log has been torn down before trying to update it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, did you handle this last comment? We need to change the shutdown ordering, or do something so if logging is shutdown while the config update is going on, we do not race?
libtcmu_log.c
Outdated
if (output->close_fn != NULL) | ||
output->close_fn(output->data); | ||
if (output->name != NULL) | ||
free(output->name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is the same as what's in log_cleanup, let's put it in a function.
libtcmu_log.c
Outdated
|
||
/* This will just find the first one and disable it. */ | ||
darray_foreach(output, logbuf->outputs) { | ||
if (output->dest == dest) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to also check for enabled == true. This would work:
- update 1.
- something does tcmu_log()
- update 2.
If there were 2 updates back to back
- update 1.
- update 2.
- something does tcmu_log()
then this would only disable the first one twice and the later delayed removal in log_output would only remove the original.
e830f34
to
8c08e80
Compare
Updated all. Thanks. |
@mikechristie, Thanks. |
Sorry. I missed your update. I will fix up this patch and merge for you. |
Hey Mike, |
How about the attached patch? I have done zero testing. |
Yeah, looks good. |
@mikechristie
|
libtcmu_config.c
Outdated
option = tcmu_get_option(#key); \ | ||
if (option) { \ | ||
cfg->key = strdup(option->opt_str); } \ | ||
cfg->key = strdup(option->opt_str); \ | ||
if (option->opt_str) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remember what TCMU_FREE_CFG_STR_KEY was for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, there is a memory leak bug introduced ahead of this PR. I will fix it together with this.
Thanks,
@mikechristie Please review. Thanks. |
@@ -180,6 +180,7 @@ static void tcmu_conf_free_str_keys(struct tcmu_config *cfg) | |||
* For example: | |||
* TCMU_FREE_CFG_STR_KEY(cfg, 'STR KEY'); | |||
*/ | |||
TCMU_FREE_CFG_STR_KEY(cfg, log_dir_path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if you do the above then you need to fix tcmu_destroy_config:
tcmu_conf_free_str_keys(cfg);
if (cfg->log_dir_path)
free(cfg->log_dir_path);
because tcmu_conf_free_str_keys call will delete cfg->log-dir_path and then the call above will try to delete the same pointer.
I actually thought the leak was if tcmu_conf_set_options is called twice. The first call would do:
cfg->key = strdup(option->opt_str); \
but then the second call would see the cfg->key is set and we would end up allocating memory again without freeing and leak the old memory at cfg->key. I thought we needed a
if (!cfg->key)
cfg->key = strdup(option->opt_str);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, updated all.
Thanks,
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
NOTE: for now this couldn't support the glfs's logging setting, and the glfs will use the old path. Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Mike Christie <mchristi@redhat.com>
Since the syslog won't logged the CDB debug logs, so there is no need to insert them in ringbuffer. Signed-off-by: Xiubo Li <xiubli@redhat.com>
NOTE: for now this couldn't support the glfs's logging setting, and
the glfs will use the old path .