I demand that Udo Richter may or may not have written... > Darren Salt wrote: >> Then there's the upgrade restart, which should be available via a signal. >> The actual restart should be deferred if VDR is currently busy. (It is >> *possible* to implement this via runvdr, but it's a lot easier to handle >> if VDR can re-exec itself.)
> Hmmmm. Some kind of i-am-idle-lets-do-a-restart state? I'm not really sure > what makes this different to the existing stuff. Maybe not much. I'm just making sure that what I see as useful here (from a packager's point of view) is heard... > Surely, an upgrade should not interrupt ongoing activity. That's reasonable but ISTM that it's something which is best left to the local admin to decide. I'll agree that recording should *normally* never be interrupted (but a forcible shutdown needs to be possible). > If the VDR does automatic shutdown, then the answer is simple: Do your > upgrade on next shutdown or restart. Thats the earliest time anyway. That's possible, but not always appropriate or even wanted. (It doesn't match how I do things, for a start.) > 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. > Some kind of temporary shutdown script could do the trick. In normal > situations, there's no shutdown because of no shutdown script, but in case > of pending updates, a temporary shutdown script does the update. > 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"?) That has problems... The update could already be installed. This is normally true when a package manager is used (it's definitely true here - I build .debs for local installation), but could also be true of an early "make install". 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. SVDRP has one advantage here, though - response codes. OTOH, I'm reasonably sure that that can be negated by kill() and getppid() or, possibly, a pipe, and I can easily adapt runvdr (well, my runvdr.c) to wait for a short time for vdr to respond... -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Another such victory over the Romans, and we are undone. _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
