Bug 100932 - Consider adding logging for command line / shell --headless usage
Summary: Consider adding logging for command line / shell --headless usage
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Depends on:
Blocks: Commandline
  Show dependency treegraph
Reported: 2016-07-15 13:43 UTC by daniel.oconnor
Modified: 2018-11-27 01:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description daniel.oconnor 2016-07-15 13:43:07 UTC
A common usecase for Libreoffice writer is to act as a headless rendering component.

While the UNO API can be used, the command line options like --convert-to seem to offer a much lower barrier to entry.

Unfortunately; things like #37531 crop up.

Examples of confused users:

 * Silent 'failure', users only figuring out they haven't installed libreoffice-writer by accident, etc.

 * Others figuring out open instances of libreoffice are getting passed commands; but missing they can specify a per user environment


While --backtrace does exist, it isn't often too helpful.

From IRC discussion:
vmiklos: most logging is done using SAL_INFO() / SAL_WARN(), and those expand to nothing on release builds.

Could a build of libreoffice (particularly what a lot of distros package up as libreoffice-headless) be configured to allow SAL_INFO/SAL_WARN to output to STDOUT/STDERR via a --verbose or --debug type argument if used with --headless.

This would keep the existing silent behaviour for desktop users, but allow semi-technical users to gain some insight if they opt in.
Comment 1 daniel.oconnor 2016-07-15 14:03:02 UTC
Somewhat similar is Bug #42982 ; which highlights a similar problem in a different area.
Comment 2 Miklos Vajna 2016-07-18 14:59:16 UTC
The big question is who will deal with the regressions caused by turning --enable-sal-log on by default. The logging is there, but when it's used, the assumption is that performance is not a problem, since in a product build they'll expand to nothing.
Comment 3 daniel.oconnor 2016-08-15 10:45:31 UTC
So, the way I had imagined it is the various logging functions simply check log level/similar. 

While not a null operation, doing

# Start up
log_level = NONE
if params["--headless"] && params["--debug=info"]
  log_level = INFO

# On logging
def log(msg)
  if log_level == NONE

  fprintf (stderr, msg)

Doesn't seem like on the face of it that you'd generate huge amounts of unnecessary IO or similar without user buy-in.

If there's a lot of stuff emitted at the wrong log level (ie: more suited to proper DEBUG level logging instead of INFO), though it may produce a bit more memory consumption the implementation would be at the same time providing a wider audience the tools to find this stuff out.
Comment 4 daniel.oconnor 2016-08-15 10:54:48 UTC
(oh, and to be super clear: I'd be more keen on a specific build - if this is already taken care of as part of the nightlys or similar and as a relative outsider, I've just missed this entirely... that'd be handy to know!)
Comment 5 Xisco Faulí 2018-11-26 18:52:50 UTC
@Mike, any opinion on this topic ?
Comment 6 Mike Kaganski 2018-11-26 19:32:11 UTC
The logging in LO is done in places that developers consider useful during the development. At no place any of developers considered the cost of logging when added it in a place (well, I exaggerate a little, but still). So the logging might happen in places called thousands of millions times during e.g. loading of a real-life file. And having a couple of additional comparisons and a couple of indirections in a tight loop might well result in a considerable penalty.

But that is just a speculation. Doers decide; so if anyone wants to give it a try, welcome to dev channel, and please feel free to try to implement the proposal (we would help answering questions, of course) - with necessary testing/profiling. If it turns out to be less problematic than anticipated - why not.
Comment 7 Xisco Faulí 2018-11-27 01:11:44 UTC
@Mike, thanks for your comment.
Considering the time this issue has been in UNCONFIRMED status and the performance penalty it might cause, let's close it as RESOLVED WONTFIX