[vdr] [RFC] Shutdown rewrite for 1.5.x

[Darren Salt]

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 :-)

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less.     USE FEWER RESOURCES.

"Pieces of nine! Pieces of nine!" ...sorry, parroty error...