Red Hat Bugzilla – Bug 600098
Last modified: 2015-05-03 21:33:56 EDT
Doesn't seem to be a text file.
Without console.log, if a machine gets crashed, we cannot know what is happening. Then we only have to login in the machine and view its console. Please solve this faster.
And the link is?
I have absolutely no problems since I installed "Open In Browser" extension to my FF.
Even without the extension you can still save it to your computer. Its not like you can't open the console.log at all.
The reason why this is happening is because the serial console includes ansi characters for screen positioning.
The "fix" is to offer a link that will strip the ansi characters.
(In reply to comment #2)
> And the link is?
> I have absolutely no problems since I installed "Open In Browser" extension to
> my FF.
This one which I can open
But another which I cannot open in FF
Then I download it and do this:
[yugzhang@dhcp-65-35 Desktop]$ file console.log
[yugzhang@dhcp-65-35 Desktop]$ vim console.log
Yes, I can see some words and magic codes there.
But this behavior is not like RHTS. IIRC, I can view console.log there in FF all the time.
You are right. This behaviour is not like RHTS. In RHTS I stripped the ansi codes on upload. I can re-implement this in beaker but I thought it was bad practice to change the log file like that.
Are you saying your ok with me doing that again? It seemed like a hack to me but I can put it back.
You know all we want to see is the information which is helpful.
If some of they are of no use and cannot be seen even via vi, I cannot see why we don't stripe them at first to facilitate our log viewing.
Bill, IMO solution suggested in Comment 3 is perfect - it keeps the data intact while offering something which can be displayed.
Ray, Igor, I got confused a bit as from description it was not clear (at least to me) what's the real problem. I am glad it is not a console.log is missing or corrupted.
I considered it a FF annoyance as it refused to display file with text/plain ContentType header.
I've added code to only strip non-ascii chars from the console.log.
Will be released Tomorrow.
this still doesn't seem to be catching *ALL* the bad chars. I still get some Null \x00 chars in the stream still.
finally fixed this. This will be in Tomorrows update as well.
*** Bug 604717 has been marked as a duplicate of this bug. ***
Fixed in Current Release.
I just found I cannot get console.log displayed in FF. But it can be displayed the day before yesterday. Now, FF always say it is a BIN file, and what I can do is to save it to disk and view it with vi.
when I use beaker's workflow-autofs, the log file still bin file:
Many logs yielded by beaker cannot be viewed directly in FF these days. Could we filter them all in one point? Previous solution is not very complete.
I oppose fiddling with test output - what the test submit that's what one gets. Either the test is wrong or take it as is.
If we were going to filter all files, I would like it to be able doing more than just stripping some chars:
- sometimes raw data are wanted, so stripping must be optional
- for console.log last N characters are often what matters instead of MiB of data
- highlighting lines containing words \b(err|warn)...
Is there a way how to tweak the way apache serve files with some modifiers?
I like what bugzilla does to the attachments:
E.g. to display last 4096 characters in raw format one could use:
running e.g. following on backend:
`cat $FILE | tail -c 4096`
The default would display whole file with stripped non-printable characters, running e.g. following:
`cat $FILE | tr -cs '\n\r\t[:print:]' '?'`
This shouldn't be a problem any more. I'm closing.