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

[Thiago Macieira]

On Friday 11 July 2014 09:13:30 Hunger Tobias wrote:
>  > 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.
> 
> AFAIK android is not using systemd/journald, so what we do there does
> not directly apply to the situation here.

It does because we use a logging system very similar to journald and the 
criteria to choose when to use that or when to use stderr is the same.

Instead of sd_journald_send, we use __android_log_print. That's the only 
difference.

>  > 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.
> 
> Sure, we can come up with case-by-case ways to get to data.
> 
> But I really want to keep the simple remote debugging use case working.
> That currently requires sshd and gdbserver to be installed on the device
> and I would personally prefer not to have additional dependencies on top
> of that.

That's there. I've given you two possible solutions to get the log sent to 
stderr in those cases.

> I found some documentation on how to configure journald to forward its
> logs to a pre-configured remote machine, which does not fit our use
> case. We need to access the logs from the machine of the developer and
> that will rarely be the central log server (I hope;-). At least
> journalctl can produce machine readable output, so we might get away by
> just retrieving that by running journalctl -o json. That is way more
> data than what we currently get via stderr, so this will need more
> bandwidth than the current approach. That might already be prohibitive
> on some hardware. But without code that is just speculation.

Right. That would be a third option, but it would also require figuring out 
what the target system is doing. Maybe for remote debugging we don't want to 
mess with journald or something else. Suppose you were ssh'ing into an OS X 
machine. Then we're not talking about journald, but about asl.

>  > 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.
> 
> I see why you would want journal data in your output, but I do see a
> problems making that work for remote debugging/running. Even sailfish is
> apparently forcing output to stderr when starting applications on-device
> via Qt Creator.

When I wrote the paragraph above, I was thinking of local debugging and 
attaching to already-running processes, processes that Creator did not launch. 
For local debugging, it's more reasonable.

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