oztoppy Forum
Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 3 of 4      Prev   1   2   3   4   Next
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #31 
Thanks; I really appreciate this. The difference may be in your trapping function; I was under the impression that all program logic is interrupted on a SIGTERM, except whatever is inside the trap. I have not tried using it as the loop condition. If the problem is files being left open, then this would probably solve it. I am using more temporary files that could cause problems, but I will let you know what happens.

Another difference might be the -TERM switch with killall; what is it? I don't see it in the man page. 

Are the start/stop commands necessary? I don't need this appearing in the menu, so I'm not sure that TMSServer needs the status returned.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 240
Reply with quote  #32 
Keith, I just updated my scripts in my previous post.  Our postings must have overlapped.
Code:
# killall --help
BusyBox v1.11.1 (2016-01-29 10:52:19 KST) multi-call binary

Usage: killall [-l] [-q] [-signal] process-name...

Send a signal (default is TERM) to the specified process(es)

Options:
        -l      List all signal names and numbers
        -q      Do not complain if no processes were killed
Code:
# killall -l
HUP
INT
QUIT
ILL
TRAP
ABRT
FPE
KILL
BUS
SEGV
SYS
PIPE
ALRM
TERM
USR1
USR2
CHLD
PWR
WINCH
URG
POLL
STOP
TSTP
CONT
TTIN
TTOU
VTALRM
PROF
XCPU
XFSZ
The status tells TMSServer if the service is: not running, already running or running.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #33 
I didn't get far. The first thing I did was copy your code exactly as it is, into exactly the same filenames, to test it. I can't seem to start the script at all; it shows red in the TMSServer interface, even when I press "play," and it produces no logging. It appears to be always returning status 0, which probably means it can't start the script. Looking into it.

So -TERM just sends SIGTERM; same as the default?
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 240
Reply with quote  #34 
The log may be in /root.

Did you chmod 777 looper?
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #35 
I assume you mean "looper". I did. Found the log; it is always returning a status of 0. I'm trying to work out why the looper isn't starting.

EDIT: Wow. Should have seen it. I had to call the file "looper" rather than "looper.sh".



0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #36 
 OK, now I am sad. "Checking HDD," on every boot. I will try adding a shutdown script, but I think this should be handled by the STOP parameter in the control script. Thanks again for trying; I think I just have to accept that my 2460, for whatever reason, is hyper-sensitive changes in its file system.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #37 
Result! Adding a .shutdown script, with the KILLALL command in it, may have done the trick. Three times, now, the script has run on startup, and Checking HDD has not occurred any of those times. I am not getting too excited until I start putting in some of my own logic, but I am cautiously optimistic. I owe you a lot, DMC.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #38 
Testing is agonising. Every time I telnet in, (to chmod, for example), I have to wait through Checking HDD afterward. It just takes too long to test changes, when it has to check two terabytes every time. If someone knows a way to disable the check while programming, it would be a godsend.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #39 
It may be the tap start API causing my problem.

When I prevent my script from running these two lines:

Code:

LOCALURL='http://'$LOCALIP':8000/api?function=tap&action=start!&filename=/mnt/hd/ProgramFiles/XStart/MediaAspect.tap'
/mnt/hd/ProgramFiles/busybox wget -q -O /mnt/hd/ProgramFiles/Scripts/tmp/tapstart.dat $LOCALURL



I avoid the "Checking HDD" problem. However, these lines do not cause the problem:

Code:

LOCALURL='http://'$LOCALIP':8000/api?function=tap&action=stop!&filename=/mnt/hd/ProgramFiles/XStart/MediaAspect.tap'
/mnt/hd/ProgramFiles/busybox wget -q -O /mnt/hd/ProgramFiles/Scripts/tmp/tapstop.dat $LOCALURL




Since the first lines are basically identical, and don't interact with the environment, I have to assume that the first API call is causing the effect, while the second is harmless. I tried a test script with the offending lines on their own in a .control file, but this caused the system to become unresponsive (as well as Checking HDD).

DMC, if you get a chance, would you mind testing just these lines on your 2400? I'm not assuming this is anything that can be "fixed," just trying to confirm that I have identified the problem.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 240
Reply with quote  #40 
Then the WebControl API requests another TAP to exit, it simply sends that TAP an EVT_STOP event and then its status is updated to "2".

I suspect that MediaAspect is holding some files open that are not closed cleanly when it exits, thus causing the "Checking HDD" message.  Looking at the source code for MediaAspect, I can not see a function to handle EVT_STOP.

With only MediaAspect open, issue the "lsof" command to see what files the PVR task has open.  This could point you to an INI file or something.

I would be interest to see how MediaAspect behaves under a number of circumstances and if we can narrow down a cause and potentially devise a workaround.

When happens when:
  1. MediaAspect is running and the PVR is powered-off via the stop button?
  2. MediaAspect is stopped via its own exit option?
  3. MediaAspect is stopped via TMSCommander?
  4. MediaAspect is stopped via the WebControl files menu from a browser?
Also, do you just have to load/unload MediaAspect, or do you have to use it to induce the "Checking HDD" message?
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #41 
Thanks for the reply. Despite its poor STOP handling, I don't think it is the Tap, but I will run test number 4. I will also try my polling script by starting and stopping a different TAP. Your other tests I have already tried.

The reason I don't think it is the Tap is because:

1) XStart starts the Tap when the system boots. My polling script then issues a "stop" command on the Tap. If this is all that happens, then there is no "Checking HDD" when I boot. It is only when I subsequently change Playmode to 2 (play a recording) that the script issues the "start" command again, and "Checking HDD" occurs. This is true even if the "stop" API is called again.

If I comment out the "start" API, there is no Checking HDD no matter what I do. XStart starts it, my script stops it, and I reboot cleanly.

In summary, don't have to use MediaAspect to invoke Checking HDD, just load it via the API. Unloading it (even via that API) does no harm.

2) Your tests 1 through 3, above, have been run. None of them invoke Checking HDD.

3) I am fairly sure that I have also tried this with ChangePreview, with the same problem, but I will try it again when I get home.



0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #42 
It appears that you are onto something. I have tried the same script with ChangePreview, and while I am occasionally receiving the Checking HDD message, I have several times started and stopped the TAP using an API, with a clean reboot afterward.

However, the MediaAspect TAP only causes a problem when I start it using the API (as above). I've thoroughly tested as many other means as I can think of of starting and stopping it, with no ill effect. I've not sure how this ties into the lack of EVT_STOP handling by MediaAspect.

I will try a few more taps, and report back.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 240
Reply with quote  #43 
Quote:
Originally Posted by keith_leitch
I've not sure how this ties into the lack of EVT_STOP handling by MediaAspect.
If the TAP has some files open and it is unceremoniously unloaded, the open file handles will not be cleaned-up and the HDD could be seen as requiring checking on next boot.

Responding to an EVT_STOP would give the TAP an opportunity to close any open files and make peace with the world before its untimely demise.

It would be interesting to see an "lsof" before and after the TAP is stopped.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #44 
Oh, yes, I did that (though only quickly). All i could see was the .ini file, which seemed to close while the tap was still running.

I then got distracted by a persistent logic bug that I can't find, so I haven't even tried the script with a third tap yet.

Unrelated to the bug, what I was trying to do when it appeared was trap SIGTERM in all of the scripts that this one calls, just to do an exit. Do you think that one of them could be the source of the remaining intermittent Checking HDD? Maybe I should move them into functions.

I understand that files left open will cause the problem. What I don't understand is why starting a tap (through the API) creates the issue, when stopping a tap does not.
0
keith_leitch

Senior Member
Registered:
Posts: 525
Reply with quote  #45 
After a few days busy with work, I have come back to this. Here is where I stand:

I am trapping a number of kill signals in the main looping script, as well as in any scripts it calls. In a shutdown script, I am using "killall" to send a SIGTERM to all of those processes. If I initiate the shutdown script manually (by pressing Stop through TMSServer), then shut down immediately, I can restart without Checking HDD. As far as I've tried, this is the case every time.

However, if I simply power off without manual intervention, Checking HDD occurs most (but not quite every) times.

Here is my current theory: Whatever signal the Topfield sends on shutdown is sometimes reaching my scripts before it reaches TMSServer, or at least before TMSServer has finished running the shutdown script. This may be a SIGKILL, which may be preventing my scripts from doing their cleanup before terminating.

Some questions:

1) Does anyone know what signal the Topfield sends running processes on shutdown?
2) Can anyone think of a way to prioritise which processes receive this signal first?

EDIT: Four times in a row, I have tried manually stopping TMSServer entirely before powering down. unsurprisingly, this prevents Checking HDD. This seems to support my theory above.

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.