[Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
Hunger Tobias
Tobias.Hunger at digia.com
Fri Jul 11 11:13:30 CEST 2014
On Thu, Jul 10, 2014 at 7:14 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> I'm not asking that distributions turn journald on if they don't want to.
> Journald is optional.
Good to have that fact stated clearly:-)
<snip section on remote debugging and having a way to force stderr>
> 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.
AFAIK android is not using systemd/journald, so what we do there does
not directly apply to the situation here.
> 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.
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.
> 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.
Does somebody have experience with reading data from journald remotely?
Best Regards,
Tobias
More information about the Development
mailing list