- ac5b000 * get rid of the code to create the drone temp dir in drones.py. This used to be necessary because we needed that directory just to run drone_utility (so we could put the pickle file there). But now we use stdin, so we don't need this anymore. (drone_utility still initializes the temp dir for its own use.) by showard · 15 years ago
- 202343e On the results drone, execute code from the results dir. by showard · 15 years ago
- 2aafd90 Need to get the drone temporary directory under the results dir as well. Added unit tests to check this and to check the behavior of attach_file_to_execution, which was being affected by this bug (but wasn't actually buggy itself). by showard · 15 years ago
- c75fded Fix the drone results dir computation. I forgot that the results don't just go under the drone_installation_directory, they go under "results" in there. by showard · 15 years ago
- 42d4498 Use drone_installation_dir for all activities on drones, including results dirs and temp dirs. Previously it would use the drone_installation_dir for executing drone_utility, but would use the scheduler results dir for everything else. by showard · 15 years ago
- f85a0b7 Explicitly release pidfiles after we're done with them. This does it in a kind of lazy way, but it should work just fine. Also extended the new scheduler functional test with a few more cases and added a test to check pidfile release under these various cases. In the process, I changed how some of the code works to allow the tests to more cleanly express their intentions. by showard · 15 years ago
- 8d3dbca Make the maximum number of refreshes before forgetting a pidfile by showard · 15 years ago
- db50276 Write host keyvals for all verify/cleanup/repair tasks. by showard · 15 years ago
- 3739978 Instrument the drone manager to allow debugging why it lost track of by showard · 15 years ago
- 1ef218d This is the result of a batch reindent.py across our tree. by mbligh · 15 years ago
- 4460ee8 When a drone fails to initialize, let the scheduler die. We used to try to carry on gracefully, but it turns out this really isn't safe. If the drone failure is due to a network condition, and the drone is actually still up, then Autoserv processes will continue to run on that drone, but the scheduler will be unable to detect or stop these processes. This can lead to dual Autoserv processes running against the same machine. by showard · 15 years ago
- ed2afea make SpecialTasks recoverable. this involves quite a few changes. by showard · 15 years ago
- bf9695d Add a call to _drop_old_pidfiles(). This method has been present since the beginning but nothing ever called it, so long-running schedulers just keep accumulating pidfiles to check for, which makes them gradually get slower...and slower.... by showard · 15 years ago
- e39ebe9 temporary fix for bug in scheduling when at capacity. if no drone has capacity, pick the one with the least load. by showard · 15 years ago
- d3dc199 Add support to the scheduler to run autoserv --collect_crashinfo after a job finishes or is aborted. by showard · 15 years ago
- f2839f6 Change killing %d to %s by showard · 15 years ago
- b18134f As discussed on the mailing list, we implemented logging with a single by showard · 16 years ago
- 35162b0 by showard · 16 years ago
- de700d3 by showard · 16 years ago
- 73ec044 by showard · 16 years ago
- 678df4f by showard · 16 years ago
- 324bf81 by showard · 16 years ago
- 0205a3e by showard · 16 years ago
- 2fa5169 by showard · 16 years ago
- c5afc46 by showard · 16 years ago
- 170873e Attached is a very large patch that adds support for running a by showard · 16 years ago