Bug 67745

Summary: RFE: strictly filter journald output to console to 7bit ascii
Product: systemd Reporter: Pacho Ramos <pachoramos1>
Component: generalAssignee: systemd-bugs
Status: NEW --- QA Contact: systemd-bugs
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: /etc/systemd/journal.conf
cat vcsa12 output
systemctl --full output
journalctl --all --full output

Description Pacho Ramos 2013-08-04 15:13:08 UTC
Created attachment 83618 [details]
/etc/systemd/journal.conf

I got the this issue last time I tried to get logs printed in tty12 (as syslog-ng was doing without any problems). Now, I have tried again to configure journald to do that and, again, I see corrupted output in tty12 after using it for some days. The problem is that I don't know what causes this corruption, as "journalctl" output looks to be ok.

I only see strange characters printed in tty12 console, if a new message is logged, I see new lines with cruft being shown in tty12. Also, I don't know how to reset that console

Thanks
Comment 1 Zbigniew Jedrzejewski-Szmek 2013-08-05 01:31:45 UTC
Screenshot or contents of /dev/vcsa12?
Comment 2 Pacho Ramos 2013-08-06 07:35:26 UTC
Created attachment 83696 [details]
cat vcsa12 output
Comment 3 Pacho Ramos 2013-08-06 07:40:53 UTC
Even being able to read generated file, it's currently corrupted when I switch to tty12 :S
Comment 4 Zbigniew Jedrzejewski-Szmek 2013-08-06 12:13:33 UTC
Based on the ttyshot you provided, it looks like the tty got put in raw mode, and the text is not being wrapper properly. It doesn't seem really garbled, but rather badly wrapped :). That mode change could be an effect of writing non-text to the tty. Looking at server_forward_console() in src/journal/journald-console.c, we make no attempt to filter binary data. So the next question is: was there anything in the logs which isn't text (the MESSAGE= part)?
Comment 5 Pacho Ramos 2013-08-06 12:47:45 UTC
(In reply to comment #4)
> So
> the next question is: was there anything in the logs which isn't text (the
> MESSAGE= part)?

How can I look for that? "journalctl" looks to show  all ok, but it's so big that probably I am missing the offending line :/
Comment 6 Zbigniew Jedrzejewski-Szmek 2013-08-06 13:50:31 UTC
Try 

  journalctl --full |grep -i '[^][a-zA-Z0-9 .,;\\=`:"~<>/?{}_+()&*^&$%@#!|'"'-]"

and adjust if valid lines still show up :)
Comment 7 Pacho Ramos 2013-08-07 09:16:41 UTC
It only shows me "valid" lines with "ó" (due spanish locale being used), also have tried to check its output for last days (as I am just seeing it corrupted in tty12 now) but neither. Will attach fill output :/

Anyway, maybe the offending lines are being filtered by journalctl... or is it also  being used for redirection to console?
Comment 8 Pacho Ramos 2013-08-07 09:18:32 UTC
Created attachment 83769 [details]
systemctl --full output
Comment 9 Zbigniew Jedrzejewski-Szmek 2013-08-08 05:06:37 UTC
(In reply to comment #7)
> It only shows me "valid" lines with "ó" (due spanish locale being used),
> also have tried to check its output for last days (as I am just seeing it
> corrupted in tty12 now) but neither. Will attach fill output :/
My bad. --full just prints printable lines in full, but to find offending lines, --all is needed. Without --all, they show up as "[xxxB blob data]". Can you please try again with --full --all?

> Anyway, maybe the offending lines are being filtered by journalctl... or is
> it also  being used for redirection to console?
No, it's not filtered.

I guess that we could add filtering to what we write to the console, but it'd like to nail the exact cause anyway. My guess might be wrong.
Comment 10 Pacho Ramos 2013-08-08 15:36:10 UTC
Created attachment 83845 [details]
journalctl --all --full output
Comment 11 Zbigniew Jedrzejewski-Szmek 2013-10-04 17:58:44 UTC
(In reply to comment #10)
> journalctl --all --full output
Hm, nothing interesting here. We have some pending utf-8 tightening patches coming up. Let's see if they help.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.