Bug 1793594

Thank you for reporting this issue, I will see if I can reproduce it on my end.

Hello,

The following command will always generate the error below(sorry, we should improve the error message here):

    [root@rhel81-reproducer-session-rec test]# LC_ALL="en_US.UTF8" tlog-play -r journal

    unexpected character
    Failed reading the source at entry 0

Could you try playing back the recording after specifying the -M tlog-play argument as well? You can follow these steps:

 - Find the recording containing the issue with 'journalctl'

     # journalctl -o verbose -r

 - Copy the recording ID from the message field:

     "rec":"ab906f9803204c0193a8968029f2acb6-f1b-6a70b"

 - Use the recording ID in the tlog-play command:

  # tlog-play -r journal -M TLOG_REC=ab906f9803204c0193a8968029f2acb6-c80-525e9

Thank you.

-Justin

(In reply to jstephen from comment #3)
Hello,

Thanks for looking into this Justin.

> The following command will always generate the error below(sorry, we should
> improve the error message here):
> 
>     [root@rhel81-reproducer-session-rec test]# LC_ALL="en_US.UTF8" tlog-play
> -r journal
> 
>     unexpected character
>     Failed reading the source at entry 0

I'm hitting that as well:

[root@rhel81 ~]# LC_ALL="en_US.UTF8" tlog-play -r journal

unexpected character
Failed reading the source at entry 0


> 
> Could you try playing back the recording after specifying the -M tlog-play
> argument as well? You can follow these steps:
> 
>  - Find the recording containing the issue with 'journalctl'
> 
>      # journalctl -o verbose -r
> 
>  - Copy the recording ID from the message field:
> 
>      "rec":"ab906f9803204c0193a8968029f2acb6-f1b-6a70b"
> 
>  - Use the recording ID in the tlog-play command:
> 
>   # tlog-play -r journal -M
> TLOG_REC=ab906f9803204c0193a8968029f2acb6-c80-525e9


Strangely this doesn't run into any issues and the recording is played back successfully. I don't have any locale config done, which is why I'm specifying the env variable prior to the execution of the command:

[root@rhel81 ~]# LC_ALL="en_US.UTF8" tlog-play -r journal -M TLOG_REC=3f020ba639fa4ed185b1bf33bae1fac0-631c-2077a
[vagrant@rhel81 ~]$ test
[vagrant@rhel81 ~]$ logout

[root@rhel81 ~]# 

Thanks!

Thank you Lucas. I believe this is a problem in the recordings list and playback of the recording in the cockpit web interface, and not in tlog itself. If you or the customer do not agree please let me know.

I'm re-assigning to the correct component and will continue investigation on my side.

(In reply to jstephen from comment #5)
Hello Justin,

> Thank you Lucas. I believe this is a problem in the recordings list and
> playback of the recording in the cockpit web interface, and not in tlog
> itself. If you or the customer do not agree please let me know.

I'm a bit confused though. If "tlog-play -r journal" seems to run into issues then isn't there something wrong in tlog-play? Or is the issue specific to certain locale configurations?

Just for reference I've faced the same error with C.UTF8 as well:


[root@rhel81 ~]# LC_ALL="C.UTF8" tlog-play -r journal

unexpected character
Failed reading the source at entry 0


If cockpit uses a similar mechanism or even tlog-play itself underneath then couldn't this be potentially related?

(In reply to Lucas Caparelli from comment #6)
> (In reply to jstephen from comment #5)
> Hello Justin,
> 
> > Thank you Lucas. I believe this is a problem in the recordings list and
> > playback of the recording in the cockpit web interface, and not in tlog
> > itself. If you or the customer do not agree please let me know.
> 
> I'm a bit confused though. If "tlog-play -r journal" seems to run into
> issues then isn't there something wrong in tlog-play? Or is the issue
> specific to certain locale configurations?
> 
> Just for reference I've faced the same error with C.UTF8 as well:
> 
> 
> [root@rhel81 ~]# LC_ALL="C.UTF8" tlog-play -r journal
> 
> unexpected character
> Failed reading the source at entry 0


This tlog-play command will always fail, it requires a -M argument to identify the recording to look for. For example: "tlog-play -r journal -M TLOG_REC=3f020ba639fa4ed185b1bf33bae1fac0-631c-2077a"

> 
> 
> If cockpit uses a similar mechanism or even tlog-play itself underneath then
> couldn't this be potentially related?

Cockpit-session-recording does *not* execute tlog-play underneath, it has it's own code which is used to aggregate a list of recordings from the journal and playback those recordings. That is why I believe the problem is specific to cockpit-session-recording, assuming tlog-play is playing back the recording correctly(with the -r journal and -M TLOG_REC=$recid argument).

(In reply to jstephen from comment #7)
> (In reply to Lucas Caparelli from comment #6)
> > (In reply to jstephen from comment #5)
> > Hello Justin,
> > 
> > > Thank you Lucas. I believe this is a problem in the recordings list and
> > > playback of the recording in the cockpit web interface, and not in tlog
> > > itself. If you or the customer do not agree please let me know.
> > 
> > I'm a bit confused though. If "tlog-play -r journal" seems to run into
> > issues then isn't there something wrong in tlog-play? Or is the issue
> > specific to certain locale configurations?
> > 
> > Just for reference I've faced the same error with C.UTF8 as well:
> > 
> > 
> > [root@rhel81 ~]# LC_ALL="C.UTF8" tlog-play -r journal
> > 
> > unexpected character
> > Failed reading the source at entry 0
> 
> 
> This tlog-play command will always fail, it requires a -M argument to
> identify the recording to look for. For example: "tlog-play -r journal -M
> TLOG_REC=3f020ba639fa4ed185b1bf33bae1fac0-631c-2077a"
> 
> > 
> > 
> > If cockpit uses a similar mechanism or even tlog-play itself underneath then
> > couldn't this be potentially related?
> 
> Cockpit-session-recording does *not* execute tlog-play underneath, it has
> it's own code which is used to aggregate a list of recordings from the
> journal and playback those recordings. That is why I believe the problem is
> specific to cockpit-session-recording, assuming tlog-play is playing back
> the recording correctly(with the -r journal and -M TLOG_REC=$recid argument).

Oh, I see, thanks for the explanation Justin!

After troubleshooting this further, I have determined this issue is actually 2 separate isolated issues(although one recording can cause both issues to present themselves). One issue in the cockpit-session-recording Player page and the other in the cockpit-session-recording Recordings List page.

1) Regarding the issue with the player page when a rsync transfer session recording generates the playback error: "SyntaxError: JSON.parse: unexpected non-whitespace character after JSON data at line 1 column 4 of the JSON data"
       
    - I fixed this upstream after reproducing the problem stated in the bugzilla description: https://github.com/Scribery/cockpit-session-recording/pull/39

2) Regarding the issue with the Recordings page not listing any newer recordings after a large recording is created:

    - Is a known issue which requires a fix by the cockpit team, as we are utilizing their API to retrieve a complete list of journal entries to parse for the Recordings list. The BZ open with the cockpit team to track this work is:  https://bugzilla.redhat.com/show_bug.cgi?id=1751783

I propose we use this BZ 1793594 to track issue number 1 described above. I will move this to POST status to be fixed in RHEL 8.3, but note the complete fix for the described problem will depend on the BZ #1751783 which has no timeframe estimation of completion.

*** Bug 1694846 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cockpit-session-recording bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4741