【发布时间】:2015-12-02 07:45:28
【问题描述】:
将附加标志“keywords::open_mode = std::ios_base::app”添加到文件接收器后,当文件达到最大大小时,不会发生正常的文件旋转,如下面的代码所示:
typedef sinks::synchronous_sink< sinks::text_file_backend > file_sink;
boost::shared_ptr< logging::core > core = logging::core::get();
boost::shared_ptr< file_sink > sink(new file_sink(
keywords::file_name = "/tmp/test.log", // log file with full path
keywords::open_mode = std::ios_base::app, // append mode set
keywords::rotation_size = 5000000
));
sink->locked_backend()->set_file_collector(sinks::file::make_collector(
keywords::target = "/tmp/", // log file & target have same dir
keywords::max_size = 5000000,
keywords::min_free_space = 100000
));
sink->locked_backend()->scan_for_files();
sink->locked_backend()->auto_flush(true);
core->add_sink(sink);
Boost 日志版本:1.59
观察到的行为: 每次使用 boost logger 的进程启动后;日志消息被附加到现有的日志文件中,而不是创建新的日志文件。但是,当日志文件达到最大大小时,不会发生提升文件轮换策略,并且会创建新的日志文件,而无需将旧日志文件移动到目标目录。
预期行为: 日志文件应附加日志消息,当达到最大大小时,应正确轮换。
如果有任何解决此问题的方法,请告诉我。
【问题讨论】:
-
任何更新或解决方案?
-
除了明显不正确的
max_size值之外,日志文件轮换对我来说效果很好。文件名test.log不包含任何占位符,所以我在tmp目录下得到test.log00000、test.log00001等。 -
另外,您应该知道,当日志文件被收集到与最初写入日志文件的目录不同的目录时,您不会在进程重新启动后追加文件。终止前进程写入的最后一个文件在退出进程之前轮换,下一个进程将在其位置创建一个新文件。只有在前一个文件没有移动到其他目录时才会进行文件追加。
-
我尝试了您的建议,并使用最近的更新编辑了问题;日志文件和目标都具有相同的目录,因此在重新启动进程后日志消息被附加到相同的日志 /test.log> 中。达到最大大小后,文件通过在 /tmp 目录中创建新的 test.log 进行轮换,但旧的日志文件被删除,而没有在 /tmp 目录中保存为 test.log00002。因此,在设置附加选项时,旋转不起作用。
-
max_size值现在等于rotation_size值。这意味着在tmp目录中不能存储超过一个完整的日志文件。所以轮换是有效的——它会删除旧文件,为新文件腾出空间。此外,旧文件不会在轮换时重命名,新文件是。见这里:boost.org/doc/libs/1_59_0/libs/log/doc/html/log/detailed/…