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...
