internal-logging: Fix issues with file logging

[alexmohr]

This commit fixes the following issues if access
to the internal log file is not possible (logging_mode = DLT_LOG_TO_FILE)

• dlt_log_free tried to call fclose on a nullptr
  Added a nullcheck for this
• Access to log file might be denied but access to logs is still wanted
  Add a new CMake option WITH_DLT_FILE_LOGGING_SYSLOG_FALLBACK
  If this is set to ON and the logging moe is set to file,
  the dlt-daemon will fall back to syslog if opening the internal log
  file failed

The program was tested solely for our own use cases, which might differ from yours.
Licensed under Mozilla Public License Version 2.0

^{Alexander Mohr, [email protected], Mercedes-Benz Tech Innovation GmbH, imprint}

[lti9hc]

Hello @alexmohr ,

I totally agree with null check in dlt_log_free()

For me, the feature "dlt-daemon will fall back to syslog if opening the internal log
file failed" is not necessary because there are some things we should take note below

• We can observe failed messages via dlt_user_printf()

• dlt-system will receive system logs and transfer it to dlt-daemon
  --> if dlt-daemon falls back to syslog mode, it means dlt-daemon will process messages one more time

There is one point that we should improve in dlt_log_init()

• switch dlt_vlog() to dlt_user_printf() --> the message could be observed in case the log can not be written in file

What do you think?

[alexmohr]

On systems w/o systemd (i.e. using sysv init or qnx) messages from standard output may be lost. We had this issue especially on qnx, because the way services are started in our project, the standard output may not be even opened.
Also it might be the case the logging on stdout is not resulting in journal logs, as this can be disabled.

I do understand your concern and that's the reason I've made it possible to disable it via build parameters.
If you insist we can move the null check and the switch form dlt_vlog to dlt_user_print into a separate MR and discuss it separately.

[michael-methner]

Hello @alexmohr , hello @lti9hc ,
thanks for the commit & discussion. The patch looks good to me.