next up previous contents
Next: Debugging Up: TROUBLESHOOTING Previous: TROUBLESHOOTING

Bugs, Blemishes, and Limitations

 

Drone makes some assumptions about the output produced by such Unix commands as rm and file, as well as about the form of the shell prompts. I've tried to make Drone as portable as possible; however, it may not recognize some output on a particular machine, in which case it will exit with an error message. A common error message that you will see in this case is timeout error. There are several debugging options to help you figure out what is going wrong; see Section 6.2 for details.

Drone currently exits with an error if anything goes wrong during a run. This may cause problems, especially if the target program is being run on remote hosts, and the network goes down temporarily or a host is temporarily unavailable. The script will be made more robust to this in a future version.

IP addresses are cached using either the nslookup or host commands, depending on the value of the parameter ipLookupMethod. I don't believe that either command is a Posix standard, and some versions of Unix may not support either one. If you know of a better alternative, please let me know.

On some platforms, Drone may try to send a shell command to a remote host that is too long for the terminal. You will know that this is happening if you start hearing beeps, or see the character ^G or \0x07. This is a limitation of the terminal driver, not the shell. To get around this problem, shorten the experiment and parameter names and reduce the length of the target program's path. See Exploring Expect [4] for more information on this problem. If all else fails, you might try entering raw terminal mode before Expect sends the lines that are giving you problems; I haven't tried this myself.

Currently, the user must have the same login ID and password on all remote hosts, and the target program must be located at the same path on all of them.

Abbreviations are not yet fully implemented.

The input file is not stored in the output directory on local hosts, even if useTmp is 1. This is not a major problem, but it may cause unnecessary accesses to a shared disk or remote file system.

Finally, if an experiment fails for any reason after it has begun, the log file is still updated. No record is made in the log file or output control file that an experiment failed.


next up previous contents
Next: Debugging Up: TROUBLESHOOTING Previous: TROUBLESHOOTING

Drone 1.01 User's Guide
Theodore C. Belding
Wed Nov 13 03:53:22 EST 1996