I demand that Udo Richter may or may not have written...
Darren Salt wrote:
I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some "Min User Inactivity" setting, or else live viewing could be interrupted by the automatic update.
The user inactivity setting isn't relevant to that, AFAICS.
If you want to do the update while there's no ongoing activity, then you'll need some kind of user inactivity, otherwise a live viewer would be interrupted instantly.
Local policy would seem to be the best way to handle this.
For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts.
(Did you mean "exits"?)
Actually, exists, in the sense that the name of a script has been set using the Shutdown.SetShutdownCommand() call.
Bad choice of word - the obvious meaning of the phrase is "when the script is created".
The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless.
Ok, a suggestion how this could be done in a simple and useful way:
We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal.
An external script could then repeat sending the SIGHUP periodically until termination did succeed.
That'd be start-stop-daemon, most likely, which means that the task would have to be backgrounded. Its -R option is useful for this - something like "-R forever/-HUP/5", I think - but it's just possible that VDR may become inactive then active without receiving a signal in between.
However, that doesn't fit in well with runvdr, or at least with my version - which you can find in this diff (which can be cleanly applied against an empty directory) as vdr-1.4.5/debian/runvdr.c: URL:http://zap.tartarus.org/~ds/debian/dists/unstable/main/source/vdr_1.4.5-1.ds.diff.gz (Link: URL:http://www.youmustbejoking.demon.co.uk/progs.sid.html#vdr)
Also, the SIGHUP effect is not delayed for an indefinite time and won't strike unexpectedly / needs thoughts on how to cancel the SIGHUP if you change your mind.
Sending a SIGTERM would obviously cancel it. :-)
That aside, I'd probably use SIGUSR1 as a cancellation (which should be as simple as clearing a flag).
And on SVDRP: Since the SVDRP rewrite is on the todo list anyway, we could add support to do SVDRP on unix domain sockets, not just TCP. Domain sockets are represented by files (like for example /etc/vdr/svdrp.socket) and access rights are controlled by the file system. This would allow to open SVDRP only for the local root, or just for the local video user group.
That could be useful. For my purposes, though, I still prefer signals :-)