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

Thiago Macieira thiago.macieira at intel.com
Fri Jul 11 01:18:52 CEST 2014

On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
> 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?

Because that's the way to do it on Windows. It's been established for 15 or 20 
years that applications log via OutputDebugString. GUI applications can't 
write to the console unless they AllocConsole or attach to an existing one -- 
and attaching is only permitted since Windows XP.

The big problem I found when implementing this is that systemd and launchd 
will capture your stdout and stderr into the system log. So if we log to both, 
then the message appears duplicated in the syslog for all applications 
launched by those tools.

> 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).

You can still install your handler to do that. We're talking about the default 
and I'd like to have a consistent behaviour across different OS. It makes my 
implementation simpler.

Logging to both is a problem if you have something that is able to read from 
both. On Windows, all debuggers and IDEs read from both. Therefore, the option 
is out.

> 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.

There you go. That's the default on OS X and will probably become the default 
on Linux if the desktops switch to user-mode systemd.

> > === 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.

I agree. Which is why my proposal email does not talk about debug mode.

> 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.

If we did it like that and if you ran debug-mode applications in your system. 
That's not a common situation. And besides, systemd will capture stderr 
anyway, just will less information.

> 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.

It isn't. Creator devs are skeptical about modifying the environment by 
default. It's bad enough that it modifies PATH during the build process -- that 
means if you build with a Qt whose tools are in /usr/bin, you lose any 
overrides you placed in PATH (such as icecc).

> > 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.

$ systemd-journalctl 
No journal files were found.

Like I said, it depends on the journald configuration. Distributions should not 
enable journald unless they also configure journald in a way that users can 
read back what they've logged.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list