Defend against reading before runguard is done writing

[vmcj]

I was testing for another PR where I kill the judgedaemon after 30s (timeout 30s ./bin/judgedaemon -n2), I suspect the judgedaemon gets a signal here, sends it to runguard which kills the submission but is not done writing yet, the judgedaemon already starts reading the file which is still empty (verified that by outputting it in the judgedaemon) but has values after the judgedaemon exits.

This check should fix that racecondition but as this is such a specific case I'm not sure if we want to slow ourselves down by reading such files twice?

[meisterT]

I don't believe the race condition as you describe it can exist. Please let me know what I am missing.

The judgedaemon calls runguard in synchronous fashion, should never do it asynchronously. In runCommandSafe we call proc_close in https://github.com/DOMjudge/domjudge/blob/main/judge/judgedaemon.main.php#L1044. According to https://www.php.net/manual/en/function.proc-close.php:

proc_close() waits for the process to terminate, and returns its exit code

So, we wait until runguard is completely done with its execution before continueing with other code flow within judgedaemon. That means it is guaranteed that the runguard has completed all of its work before calling parseMetadata. Of course runguard can crash (or be killed), but also means that whenever we receive back control, it cannot write more data to the metadata file.