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

Unexpectedly creates a file named ./profanity #1518

Closed
mwgamera opened this issue Apr 2, 2021 · 7 comments
Closed

Unexpectedly creates a file named ./profanity #1518

mwgamera opened this issue Apr 2, 2021 · 7 comments
Assignees
Labels
Milestone

Comments

@mwgamera
Copy link

mwgamera commented Apr 2, 2021

Current Behavior

After running for a while (apparently when the log file reaches the maxsize limit), profanity changes the log file location to profanity in the current working directory.

Expected Behavior

It shouldn't do that.

Steps to Reproduce

  1. Ensure ./profanity doesn't exist and . is writable.
  2. Run profanity -l DEBUG (but without -f) to make it write a lot of log.
  3. Set /log maxsize 64.
  4. Do anything DEBUG-log-worthy like issuing any command.
  5. Observe ./profanity being created.

Possible Solution

Pass NULL as a second argument of log_init in _rotate_log_file:

profanity/src/log.c

Lines 249 to 260 in 1ec6065

char* lf = strdup(mainlogfile);
char* start = strrchr(lf, '/') + 1;
char* end = strstr(start, ".log");
*end = '\0';
log_close();
rename(log_file, log_file_new);
log_init(log_get_filter(), start);
free(lf);

Apparently, the _rotate_log_file function tried to extract user-provided name from currently used mainlogfile and restart logging to the same place after rotation, but currently this is interpreted as a full path instead. As I understand, the log rotation is no longer done with user-provided paths at all so this should be simply skipped altogether now as passing any non-NULL value is interpreted as user-provided. Replacing start with NULL appears to fix it for me.

@raspbeguy
Copy link
Contributor

Can confirm that, with up-to-date master version.

@jubalh jubalh added the bug label Jun 10, 2021
@jubalh jubalh added this to the 0.11.0 milestone Jun 10, 2021
jubalh added a commit that referenced this issue Jun 28, 2021
See #1518
It has a good explanation of what happened:

```
Apparently, the _rotate_log_file function tried to extract user-provided
name from currently used mainlogfile and restart logging to the same
place after rotation, but currently this is interpreted as a full path
instead. As I understand, the log rotation is no longer done with
user-provided paths at all so this should be simply skipped altogether
now as passing any non-NULL value is interpreted as user-provided.
Replacing start with NULL appears to fix it for me.
```

In log_msg() we only rotate the log if not user_provided_log.

#1455 changed the
behaviour from user defined filename in the log dir to using full path.
@jubalh jubalh self-assigned this Jun 28, 2021
@jubalh
Copy link
Member

jubalh commented Jun 28, 2021

@mwgamera can you test whether #1563 fixes this?

@jubalh jubalh closed this as completed Jun 28, 2021
@mwgamera
Copy link
Author

Yes, it fixes it and I can no longer reproduce it on master. But I think it introduces another subtle bug that the file will be rotated at most once because log_file = g_strdup(mainlogfile) is not NULL so log_init will set user_provided_log to TRUE.

@jubalh
Copy link
Member

jubalh commented Jun 29, 2021

You mean in _rotate_log_file()? That function is only called if user_provided_log is false.

@mwgamera
Copy link
Author

Yes, and as _rotate_log_file invokes log_init with non-NULL log_file, it changes the value of user_provided_log from FALSE to TRUE here:

profanity/src/log.c

Lines 152 to 163 in 482f895

log_init(log_level_t filter, char* log_file)
{
level_filter = filter;
tz = g_time_zone_new_local();
if (log_file) {
user_provided_log = TRUE;
}
gchar* lf = files_get_log_file(log_file);
logp = fopen(lf, "a");

Unless I'm missing something, when _rotate_log_file is reached, the actual path returned by files_get_log_file(NULL) should be the same as current mainlogfile. The only difference is that non-NULL log_file also sets user_provided_log to TRUE disabling further rotations.

@jubalh
Copy link
Member

jubalh commented Jun 29, 2021

Ah yes, so it should actually pass NULL. Do you want to make a PR?

@mwgamera
Copy link
Author

No, please handle it in whatever way you like.

jubalh added a commit that referenced this issue Jul 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants