RS not seen boxes since pm 31/1/19

peterworks

peterworks

Ye Olde Bowler
Neither of my boxes have been seen by RS since approx 14:30 yesterday (see attached). I have tried to schedule a recording and I have restarted the router but still no joy.
Only changes (I think) made has been to install Samba.
Any problems at the RS server end ?
Capture01-02-2019-10.17.03.jpg
My unique IDs are in my signature

Edit: Here is a section of the RS.log:
Capture01-02-2019-10.24.00.jpg
 
I've had a "not seen" message for one of mine (last contact 2am) - it's not crashed so assume it's an external problem.
The other is working OK with RS.
 
The one that is working hasn't updated to all the beta packages (although it should have done).
The one that isn't working has done, and the pertinent things from the rs.log would seem to be (in no particular order, as I've sorted and uniq'd it):
/mod/sbin/rs_process:53: Error: child killed by signal SIGSEGV
/mod/sbin/rs_process:62: Error: /mod/bin/rs: can't load library 'libssl.so.1.1'
/mod/sbin/rs_process:62: Error: child killed by signal SIGSEGV
Click to expand...
And probing a little further:
Code: 
humax# rs push
Sending TBL_RESERVATION schedule information to remote server.
Segmentation fault
 
Both my T2s have the same error report in their rs.log.
In addition, their "Visual Schedule" shows just one empty display line dated "Wed 31/12/69", although the "Recording List" looks OK.
At the RS, there are queued commands for both the T2s; the commands were queued last night. Neither T2 has been seen since 4:20pm yesterday. I wonder if that was when I ran the package update (for webif and a load of jim betas). Not sure which log might confirm when I did that update?

When I view the Visual Schedule the webif-error.log adds
Code: 
9    at file "/mod/webif/html/sched/visual/index.jim", line 353
8    in procedure 'render_timeline' called at file "/mod/webif/html/sched/visual/index.jim", line 437
7    /mod/webif/html/sched/visual/index.jim:353: Error: can't read "slotid": no such variable
 
And debugging the rs crash, the last thing it does immediately after connecting the socket to the rs server is this:
clock_gettime(CLOCK_MONOTONIC, {684085, 805733000}) = 0
clock_gettime(CLOCK_MONOTONIC, {684085, 805952000}) = 0
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 5
fstat(5, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
poll([{fd=5, events=POLLIN}], 1, 10) = 1 ([{fd=5, revents=POLLIN}])
read(5, "&'\360J%\210\206\251\356x\242*V\261\343\255\306\227\300i6\254\305h\343\30\31\327\vy\2115", 32) = 32
close(5) = 0
getuid() = 0
time(NULL) = 1549021560
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
Click to expand...
 
Let me push an updated rs to the beta repository.
Edit: done..

PS: It's nice that the beta is shaking issues out : )
 
Comparing the strace outputs further between working and non-working box, I see rs appears to be trying to use the new ssl stuff.
So I set "LD_LIBRARY_PATH=/lib:/usr/lib:/mod/lib" instead of having /mod/lib first, re-ran the "rs push" and it didn't crash.
Then I moved away /mod/lib/libssl* to somewhere else and everything rs related is now hunky-dory again.
 
You must log in or register to reply here.
Back
Top