Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 600098 - console.log
console.log
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.5
All Linux
high Severity urgent (vote)
: 0.5.42
: ---
Assigned To: Bill Peck
: Reopened
: 604717 (view as bug list)
Depends On:
Blocks: 593365
  Show dependency treegraph
 
Reported: 2010-06-03 18:57 EDT by Raymond Mancy
Modified: 2015-05-03 21:33 EDT (History)
11 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Raymond Mancy 2010-06-03 18:57:50 EDT
Doesn't seem to be a text file.
Comment 1 Igor Zhang 2010-06-04 02:19:36 EDT
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 08:49:35 EDT
And the link is?

ADVERTISING:
I have absolutely no problems since I installed "Open In Browser" extension to my FF.
Comment 3 Bill Peck 2010-06-04 09:14:57 EDT
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 09:42:12 EDT
(In reply to comment #2)
> And the link is?
> 
> ADVERTISING:
> I have absolutely no problems since I installed "Open In Browser" extension to
> my FF.    

This one which I can open
https://beaker.engineering.redhat.com/logs/2010/43/2043/3826///console.log

But another which I cannot open in FF
https://beaker.engineering.redhat.com/jobs/1879

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 09:54:42 EDT
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 10:04:54 EDT
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 10:39:38 EDT
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 16:53:55 EDT
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 17:08:56 EDT
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 15:44:14 EDT
finally fixed this.  This will be in Tomorrows update as well.
Comment 11 Bill Peck 2010-06-16 11:24:26 EDT
*** Bug 604717 has been marked as a duplicate of this bug. ***
Comment 12 Bill Peck 2010-06-16 15:01:34 EDT
Fixed in Current Release.
Comment 13 Han Pingtian 2010-07-21 20:06:18 EDT
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.

https://beaker.engineering.redhat.com/recipes/14694
Comment 14 yanfu,wang 2010-09-16 02:39:04 EDT
when I use beaker's workflow-autofs, the log file still bin file:
https://beaker.engineering.redhat.com/logs/2010/06/18406/34438/428862/1267089///test_log--CoreOS-autofs-bugzillas-bz130467-client.log
Comment 15 Igor Zhang 2010-09-16 02:47:48 EDT
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 04:01:22 EDT
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:

  https://bugzilla.redhat.com/attachment.cgi?id=445840
  https://bugzilla.redhat.com/attachment.cgi?id=445840&action=diff

E.g. to display last 4096 characters in raw format one could use:

  http://server/logs/path/name.log?last=4096&format=raw

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 15:45:52 EST
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.