[Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Robin Burchell]

On Wed, Jul 9, 2014 at 11:43 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> == Problematic ==
> Qt 5.3 and dev are currently able to send the output of qDebug, qWarning and
> the rest of the logging framework to somewhere other than stderr. That's done
> on Windows, BlackBerry, Android, and on Linux systems with journald.
> Additionally, there's a pending patch for OS X to use the Apple System Log [5]
> and I had a patch for MeeGo that made it go to the standard Unix syslog.
>
> We have a problem of wanting a cake and eating it too:
>
> 1) we want applications to send their logging to the system log where
> possible, which usually logs more information like the log level, time,
> application name and PID. Such a system is searchable and may allow us to add
> additional information, like the category (for category logging), file name,
> line number, function context, etc.
>
> 2) we also want to see the output when we run applications from the terminal
> or capture the output with QProcess.
>
> The absence of output causes bug reports like [2] and [4].

Let me explain why I implemented the journald-logging support the way I did.

Some background: on Sailfish, we launch all major system services (and
UI) through systemd services (& user session for the UI parts). Those
processes may then choose to execute processes of their own (the most
prominent example being the UI environment which will launch
applications in response to user input). With a default setup, systemd
will log everything sent to stderr of systems-launched processes, and
child-launched processes will have their stderr output attributed to
the systemd service which launched them.

I implemented support for this because the situation as described
above is frankly unusable for us. Output was wrongly attributed to
parent processes, which made tracking down the real source of a
problem interesting at times. The other stuff we got (like categorized
warnings, a globally usable log - to view whole system effects of
things - etc, are just icing on the cake)

I wanted to send all non-interactive logging output to systemd.
Interactive output (such as running things by hand) should go to the
console, on the assumption that there is someone actively monitoring
the other end (hence the console check).

I added the environment variable workaround after this very problem
(QtCreator output) came in in Sailfish. We then adapted our Creator
setup to set the environment variable:

https://github.com/sailfish-sdk/sailfish-qtcreator/commit/cc880444b433bc3a86305601c1471ffd292c737e
https://github.com/sailfish-sdk/sailfish-qtcreator/commit/34c8fcf9d8f749796a7f43fb52997c43f286c480


> == Solutions ==
> === Heuristically determine at runtime where to send the log ===
> Which is what I'm trying to do above.
>
> On Windows, we check whether we have a console and whether stderr is not NUL.
>
> On Unix, I have implemented the same checks.
>
> We can also use the fact of whether the main application is in debug mode or
> not.

I think this is the nicest option, as said above. I may be biased, in
that I wrote the initial implementation for journal logging :-)

That having been said, as with all heuristics, I think we should
strive to make them as simple as possible, otherwise they're going to
become non-obvious.

My vote would be to just have the correct environment variable
injected. It's our knob to customize this behavior already. It's our
knob, and we're also responsible for the behavior of it, so why not
make use of it? I understand the knee-jerk reaction to modify
application \environment, but we're talking about Qt changing Qt's
behavior through a public environment variable here, not rocket
science, KILL_ALL_HUMANS, LD_PRELOAD, or anything scary
.
BR,
Robin