3

We are using the simplest version of boost.log v2 with BOOST_LOG_TRIVIAL ( severity ) << ...

For the moment we would not like to create a separate sink or output file, sometimes redirecting the console output to a file is good enough for our purposes. Under CentOs 7 with boost.log v1.59 we have noticed that many times the output is not redirected but instead lost completely when using various redirection options like <executable> 2>&1 out.txt etc. The file ends up with zero length and no screen output is present naturally.

Has anybody observed this behaviour? Is there a known fix? Many thanks, filimon

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
filimon
  • 61
  • 4

3 Answers3

0

The syntax 2>&1 out.txt is not how you redirect output to a file. If you want to redirect both stdout and stderr to a file, you need to do either >& out.txt or >out.txt 2>&1. The first form is not supported by all shells, but the second form should be.

Kurt Stutsman
  • 3,994
  • 17
  • 23
  • 1
    Thanks, this was just an example, none of the known redirection methods works tried by many different experienced unix users. So the problem is not related to this syntax. We routinely redirect output by other std::cout or std::cerr statements without issues since years... – filimon Feb 23 '16 at 17:08
  • The default sink in Boost.Log writes output to stdout, as you can see in the code, so the problem clearly has something to do with how you redirect the output or how to setup the standard output streams in the application or its parent. Also, verify that the logs are actually written by the application and not, e.g. filtered away. – Andrey Semashev Feb 24 '16 at 12:39
0

thanks, I have seen that the trivial logging is basically std::cout this is why I am surprised it does not work as expected (and I also explained it to the colleagues who complained...). The logging output works perfectly for us on console. Not sure what you mean by "setup the standard output streams in the application or its parent", I only do in my main()

boost::log::core::get()->set_filter ( boost::log::trivial::severity >= vm["boost_log_level"].as() );

and this works as expected on the console for different command line settings of severity level when simply doing BOOST_LOG_TRIVIAL (...) << ...

Any specific pointer on where to look at in more detail to debug this? Could it be some thread-related issue, I do get my initialization messages from one thread but seem to miss the ones for another thread, as I said this only happens when redirecting, I can happily see the messages from all different threads in the console...

filimon
  • 61
  • 4
  • What I meant by "setup the standard output streams in the application or its parent" is that if you run your application from another process with `fork`+`exec` then you should have a look if you're doing something special about the standard IO descriptors as well. – Andrey Semashev Mar 29 '16 at 09:44
  • Hi, we are actually starting the process like this: crontab script1.sh -> script2.sh where in script2.sh we have nohup process >> log.txt 2>&1 &. Could the nohup be cuasing the issue? Is there a way to replace the stream in the library to be stderr instead of stdout for the console output? – filimon May 10 '16 at 08:36
  • Yes, nohup could be the cause. See its man page. http://linux.die.net/man/1/nohup – Andrey Semashev May 10 '16 at 11:07
0

This is explanation of that happens not what could be done. Output is buffered, that's why you can't see anything in file but can see in console. Just wait for it to reach 4096 bytes. Need some way of flushing the buffer...

gena2x
  • 365
  • 2
  • 12