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

Date-based log rotation? #210

Closed
DarrenCook opened this issue Sep 18, 2014 · 9 comments
Closed

Date-based log rotation? #210

DarrenCook opened this issue Sep 18, 2014 · 9 comments

Comments

@DarrenCook
Copy link

I've been using datestamp in the log filename:
FILENAME = "%datetime{%Y%M%d}.log"

For long-running processes this means it is still writing to 20140915.log a few days later. What is the recommended way to deal with this?

I can trigger a timer to run at midnight, but then I'm not sure what command to run to tell it to start a new log file, with a new filename.

@abumq
Copy link
Owner

abumq commented Sep 18, 2014

Have a look at Log file rolling and see if helps

@DarrenCook
Copy link
Author

Thanks Majid. That is not quite what I'm after: what I want to do is at a certain point of time is just change the filename of the log file that is being written to. The current size of the existing file does not matter. E.g. in a simple C-style logging system, where I have a global FILE* log_fp, what I would do (inside a mutex lock) is:

 newFilename = "...";  //Make based on current timestamp
 fclose(log_fp);
 log_fp = fopen(newFilename,"w");

I imagine there is something inside Easylogging++ that does what I need, but is any of it exposed in the public API?

@abumq
Copy link
Owner

abumq commented Sep 18, 2014

There is no internal timer that does it but you can certainly do what you are asking for using file rolling - this is theory so may want to test things

Write your PreRollOutCallback which will:

  1. check change of date and reconfigure logger with new filename if needed
  2. you may need to reinitiate logger.
  3. backups current file (check this out)

If your application is multithreaded, ensure you test that it doesn't deadlock any locks

@DarrenCook
Copy link
Author

Thanks Majid. I already have the timer, what I don't know how to do is tell the logger to close and re-open a file. Poking through the source, I think what I need is this function:

void closeAndReopenLogs(){
foreach(level){
  base::type::fstream_t* fs = unsafeGetConfigByRef(level, &m_fileStreamMap, "fileStream").get();
  if(fs == nullptr)continue;
  std::string fname = unsafeGetConfigByRef(level, &m_filenameMap, "filename");
  fs->close();
  fs->open(fname, std::fstream::out | std::fstream::app);
  }
}

I don't actually want to do it for each level, though, just once per log file. However, I've only found functions that take level so far.

The std::fstream::app is important: if the filename has not changed I want it to carry on logging to the same file, and not lose any data. I could then call closeAndReopenLogs() hourly, happily ignorant of whether my end user has configured a logging filename of:

FILENAME = "%datetime{%Y%M%d}.log"

or:

FILENAME = "%datetime{%Y%M%d%H}.log"

or even one file per month:

FILENAME = "%datetime{%B%Y}.log"

@abumq
Copy link
Owner

abumq commented Oct 5, 2014

There is no such way but I am accepting this as suggestion since some libraries support it.

@easylogging
Copy link
Contributor

In your timer, use Loggers::reconfigureAllLoggers(ConfigurationType::Filename, "path/to/logs/my-new-date.log")

This will reconfigure all the loggers with new file name and it will now write to new log file.

@DarrenCook
Copy link
Author

I finally got to looking at this, and wrote a blog post (with a complete test program):
http://darrendev.blogspot.com/2015/06/easylogging-how-to-get-one-log-file-per.html

I keep my filename in an external config file, so used a slightly different approach to your above suggestion. But it appears to be working nicely. :-)

@hyjin
Copy link

hyjin commented Jan 13, 2016

Does reconfigure handle closing the file stream?
I'm observing the old files remain opened. (I used lsof.)

@baiwfg2
Copy link

baiwfg2 commented Sep 24, 2017

@abumusamq I see the roll-out.cpp. It's a single-thread program. What if multi-thread ? Does the callback need to be locked ? system call would do mv operation, which may be problematic under multi-thread situation. Moreover, static global variable idx is also need to be protected. Right?

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

No branches or pull requests

5 participants