Reply with quote
Just to finish this up: I removed the Busybox Telnet server from the list (just by renaming the control file) and tested for nearly a week. All the problems with that control file (and the others) disappeared even when I was running the Telnet TAP.
Yesterday, I then backed up and reinstalled TMSServer with its original scripts, and the conflict returned even before I put my custom scripts back in place. It seems that the problem lay in one control script detecting the TelnetD server that the other TAP was running. That makes perfect sense. The part I don't understand is that this seemed to be causing a kind of domino effect on the control scripts for the other servers in the list after it, which no longer seemed to know if they were started or stopped. So, after I had that network problem, I kept running the TMSTelnetD TAP to troubleshoot it, and that kept messing up my NFS server. Removing the Busybox server solved the problem again, and I still have the other Telnet server to use. All is very stable. My takeaway from this is to check for software with conflicting names if any of the TMSServers behave unpredictably. I can't think of any other conflicts that might arise, but it's worth keeping in mind. This TAP is a godsend for PVR control.