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. >> 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. > 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. Also, the SIGHUP effect is not delayed for an indefinite time and wont strike unexpected / needs thoughts on how to cancel the SIGHUP if you change your mind. 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. Cheers, Udo
