If you are running Cooja on the BSOE “dance” compute servers, then you may have discovered that sometimes it’s not possible to start a second command-line simulation when one already is running. There two things that you can do to reduce the number of times that this problem affects your simulations.
Write to Unique Testlogs
Normally COOJA writes a testlog to a path like
./contiki/tools/cooja/build/COOJA.testlog
To avoid simultaneous COOJA instances from interferring with each other, modify ScriptRunner.java to include the PID in the file name. One consequence of this change is that many old test logs will accumulate in the /soe/yourlogin/contiki/tools/cooja/build directory. Periodically delete these log files.
You will find scriptRunner.java at a path like
./java/org/contikios/cooja/plugins/ScriptRunner.java
Make these changes:
Add an import statement after the other import statements.
import java.lang.management.ManagementFactory;
After the test for a NULL logWriter, create a filename that includes the PID.
if (logWriter == null) { /* Warning: static variable, used by all active test editor plugins */ // Create a fileName that includes the PID. String PID = ManagementFactory.getRuntimeMXBean().getName().split("@")[0]; String uniqueFileName = "COOJA." + PID + ".testlog"; File logFile = new File(uniqueFileName);
Just before the String command[] is created, create a filename that includes the PID.
// Create a fileName that includes the PID. String PID = ManagementFactory.getRuntimeMXBean().getName().split("@")[0]; String uniqueFileName = "COOJA." + PID + ".testlog"; final File logFile = new File(coojaBuild, uniqueFileName);
Staggered Starts
If you try to start several background jobs, you may discover that even with the changes mentioned above, there will be interference. To help reduce the likelihood of interference, stagger the starts. For example, you could make a script that starts several background make commands, but delays their initial execution to be 3 minutes apart.
make -f cmaes1.mak < lotsofnewlines.txt > make1.out & sleep 180 make -f cmaes2.mak < lotsofnewlines.txt > make2.out & sleep 180 make -f cmaes3.mak < lotsofnewlines.txt > make3.out & sleep 180 make -f cmaes4.mak < lotsofnewlines.txt > make4.out & sleep 180 make -f cmaes5.mak < lotsofnewlines.txt > make5.out & sleep 180 make -f cmaes6.mak < lotsofnewlines.txt > make6.out & sleep 180 make -f cmaes7.mak < lotsofnewlines.txt > make7.out &
In this example, each of the different makefiles cmaes#.mak set the “all” target to be a unique lists of simulation targets, and then they include a main makefile that actually defines how to run the simulations.
.PHONY: all all : target1 include cmaes.mak
Give the Simulation Newlines
This may no longer be needed, but at one time it seems to help by redirecting stdin of each submitted background job to a text file that had several hundred empty lines. Then if the simulation needed someone to press an Enter key, it would continue on.
The makefile example above shows this change.
After making all of these changes, you still may have a few aborted simulations (for me it’s about 4%). So when necessary, I delete any partial log files and rerun make.