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

[Thiago Macieira]

On Thursday 10 July 2014 11:05:03 Tobias Hunger wrote:
> Hi Thiago,
> 
> Basically I agree with your statements, but I do not think we can rely
> on journald at this time.

Agreed.

> The first problem is of course systemd itself: Ubuntu is one of the
> biggest distros out
> there and we can not reasonably assume that to be running systemd
> before 14.04 is
> at the end of its life-cycle. Considering that this is a long term
> support release that
> will be a while. But even when systemd is in use journald might be disabled
> or misconfigured -- as you already said yourself. I hope gnome and KDE
> starting to depend
> on systemd user sessions will get that sorted out soon, but at this
> time those changes are
> not yet deployed in distributions.

I'm not asking that distributions turn journald on if they don't want to. 
Journald is optional.

However, they *can't* turn it on until we figure out how to read back what gets 
logged there. At this point, the showstopper is in journald itself.

> So I think being able to rely on logging to journald is still a long
> time off. So what is the fallback? Stderr again?

Yes. If you don't turn journald on (it's optional), then we always fall back 
to stderr.

> Adding Journald into the picture will also make retrieving warnings
> from remote machines
> a lot more difficult. Currently we rely on SSH and/or gdbserver to
> retrieve all application
> output on Unix systems. I am not sure at this time how that would work
> if the application
> starts sending output to the journal. So having a way to force stderr
> in favor of system logs
> would be greatly appreciated.

It's there in two ways:

1) Option -t to ssh, which forces the allocation of a TTY and, thus, logging 
to stderr
2) The environment variable

Note that it's also possible to query the system log remotely too. I believe 
that is done on Android, isn't it? From all I can find on the Internet, in 
order to enable capture of stderr, you need to have a rooted device.

I meant that each plugin for remote systems needs to decide how it's going to 
approach this problem. If it can access the remote log, all the better. If it 
can't, the best way is to use ssh -t -- with the added benefit that it causes 
stdio to become line-buffered. If ssh is not getting used, make sure the 
environment variable is set.

And there's another advantage: if Creator is able to query the system log, it 
is also able to print the output of an already-running application that you 
attached the debugger to.

> PS: Creator not supporting getting logs from system logs on Unix systems
> is not a bug, it is a feature nobody requested so far:-)

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