Bug 600098 - console.log
Summary: console.log
Alias: None
Product: Beaker
Classification: Community
Component: scheduler   
(Show other bugs)
Version: 0.5
Hardware: All
OS: Linux
urgent vote
Target Milestone: 0.5.42
Assignee: Bill Peck
QA Contact:
Keywords: Reopened
: 604717 (view as bug list)
Depends On:
Blocks: 593365
TreeView+ depends on / blocked
Reported: 2010-06-03 22:57 UTC by Raymond Mancy
Modified: 2015-05-04 01:33 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-15 20:45:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Raymond Mancy 2010-06-03 22:57:50 UTC
Doesn't seem to be a text file.

Comment 1 Igor Zhang 2010-06-04 06:19:36 UTC
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.

Comment 2 Marian Csontos 2010-06-04 12:49:35 UTC
And the link is?

I have absolutely no problems since I installed "Open In Browser" extension to my FF.

Comment 3 Bill Peck 2010-06-04 13:14:57 UTC
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.

Comment 4 Igor Zhang 2010-06-04 13:42:12 UTC
(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 
console.log: data
[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.

Comment 5 Bill Peck 2010-06-04 13:54:42 UTC
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.

Comment 6 Igor Zhang 2010-06-04 14:04:54 UTC
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.

Comment 7 Marian Csontos 2010-06-04 14:39:38 UTC
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.

Comment 8 Bill Peck 2010-06-08 20:53:55 UTC
I've added code to only strip non-ascii chars from the console.log. 

Will be released Tomorrow.

Comment 9 Bill Peck 2010-06-09 21:08:56 UTC
this still doesn't seem to be catching *ALL* the bad chars.  I still get some Null \x00 chars in the stream still.  

still experimenting.

Comment 10 Bill Peck 2010-06-15 19:44:14 UTC
finally fixed this.  This will be in Tomorrows update as well.

Comment 11 Bill Peck 2010-06-16 15:24:26 UTC
*** Bug 604717 has been marked as a duplicate of this bug. ***

Comment 12 Bill Peck 2010-06-16 19:01:34 UTC
Fixed in Current Release.

Comment 13 Han Pingtian 2010-07-22 00:06:18 UTC
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.


Comment 14 yanfu,wang 2010-09-16 06:39:04 UTC
when I use beaker's workflow-autofs, the log file still bin file:

Comment 15 Igor Zhang 2010-09-16 06:47:48 UTC
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.

Comment 16 Marian Csontos 2010-09-16 08:01:22 UTC
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)...

Anything else?

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:]' '?'`

Comment 17 Bill Peck 2010-11-15 20:45:52 UTC
This shouldn't be a problem any more.  I'm closing.

Note You need to log in before you can comment on or make changes to this bug.