#2888: race condition writing properties.ini in simfactory
| Reporter: | Roland Haas |
| Status: | new |
| Milestone: | |
| Version: | |
| Type: | bug |
| Priority: | major |
| Component: | SimFactory |
Currently bot the submit() as well as the run()function in lib/simrestart.py write (update) the file output-NNNN/properties.ini. In particular submit() does so after submitting to record the jobid field while run() does so before running to record the checkpointing value.
This means that if (eg on SLURM where jobs start quickly, an particular when the submit command contains a sleep 5 to slow down job submission) there can be race condition:
submit writes initial copy of properties.ini lacking jobidsubmit submits the job to SLURMproperties.inisubmit writes updated properties.ini with jobidrun writes properties.ini with checkpointingat this point jobid is lost from properties.ini
Fixes would be:
properties.ini which submit only release once it has done its final updatesbatch --hold) and only release them once the final update of properties.ini has happenedboth will require updates to simfactory’s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement hold and release commands in simfactory. The first option will require fallback code in case the lock file is left behind (e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway). The lock file will require at least some level for POSIX conformance from the file system (namely that file creation and removal is an atomic operation cluster-wide).