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

Alejandro Exojo suy at badopi.org
Fri Jul 11 00:17:48 CEST 2014


El Wednesday 09 July 2014, Thiago Macieira escribió:
> === Log to both ===
> Aside from the extra overhead, this causes systems that capture both stderr
> and the system log to record and display the same message twice. That's the
> source of task [3].
> 
> This is not an option.

Why not? Task [3] is an issue in Qt Creator, isn't it? Why it needs to read 
the system log on Windows?

Logging to the console _and_ journald has proven very useful to us. We did it 
specifically for an application using Qt's API, and developers can code, press 
Run (in Creator), and see the output in the same window with all the 
QT_MESSAGE_PATTERN goodness. Afterwards, if it's too noisy, or if you disabled 
some category, you can check the logs on journald (we logged all categories, 
even the disabled ones, to the journal, since we had or own message handler).

It's not hard at all to do it on your application if you want to fine tune it. 
Actually, I never expected to see the journald logging in Qt, but having it 
IMHO it's a boon, since you can use the feature for 3rd party applications.

Only downside is that you might need to collect what your application outputs 
to stderr from a non-Qt library. Then yes, you might get duplicated messages.

> === Heuristically determine at runtime where to send the log ===
> 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 see this as two orthogonal things. Why would one prefer the console on a 
debug build? You might need to put the program in debug mode on the target 
hardware (only device where you have the peripherals), and need the enriched 
system logging and the debug symbols.

This is the most inconvenient change, since you might need to change the 
systemd unit file to set the QT_LOGGING_TO_CONSOLE environment variable to have 
the built in journald logging.

> == Summary of systems ==
> System services on Linux with journald:
>  - default stderr: captured into system log
>  - system logging: available
>  - is stderr useful: yes, for launching from terminal

Note that you can teach systemd to ignore stderr/stdout if wanted. If the app 
is written with Qt, that can be a sane default.
 
> And then some desktop Linux distributions decided to enable journald. The
> effect of that is task [6]: Qt Creator shows no output because it goes to
> journald.

But this comment is/was in the code:

"We use isatty to catch the obvious case of someone running something 
interactively. We also support environment variables for Qt Creator use (...)"

I thought that it was agreed/known to Qt Creator developers that 
QT_LOGGING_TO_CONSOLE might be gently defaulted to true for applications run 
by Creator.

That environment variable seems like "API" to me, and a useful one that 
Creator could use. Of course they couldn't predict some distributions would 
pass -journald to configure.


From the other messages:

> * Support for journald in the pre-built Qt binaries:
> Disabled.

Probably will be that way for a long time. If Qt binaries are built with and 
old Ubuntu, they just don't have libsystemd-journal.

> Note: if journald is writing to volatile storage, regular users can't read
> the log. Therefore, system logging is not available.
> 
> Linux distributions should not enable journald logging unless regular users
> can read the output.

I think users can read their user journal, independently of the storage. This 
is as user nobody:

$ systemd-journalctl
Showing user generated messages only. Users in the group 'adm' can see all 
messages. Pass -q to turn this message off.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net



More information about the Development mailing list