[crac] RFR: CRaC may exit before image dump is completed [v3]

Roman Marchenko rmarchenko at openjdk.org
Mon Mar 6 12:43:13 UTC 2023


On Wed, 1 Mar 2023 16:30:47 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Returning status of the child only
>
> src/java.base/share/native/launcher/main.c line 120:
> 
>> 118:         pid = wait(&st);
>> 119:         if (pid == g_child_pid && WIFEXITED(st)) {
>> 120:             status = WEXITSTATUS(st);
> 
> Sorry for nit-picking, but now if the java was killed (`WIFEXITED == false`) we won't update status and will return `0`, which does not look correct. `restorewait` in this situation returns `1` [1], although better, also does not look perfect. Here I suggest be at least consistent with restorewait.
> 
> Or we can fix restorewait as well, indicating being killed by returning `128+signal`, as described in the bash manual [2]. How does it sound?
> 
>> When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status.
> 
> [1] https://github.com/openjdk/crac/blob/crac/src/java.base/unix/native/criuengine/criuengine.c#L306
> [2] https://linux.die.net/man/1/bash

@AntonKozlov 
I personnally would prefer to exit 0 on checkpoing to indicate the process is succussfully finished. On the other hand I have no idea how can we recognize cases the child process is actually killed by someone else. So I agree with idea to return an appropriate code 128+N, as well as for restorewait, to keep it consistent.

-------------

PR: https://git.openjdk.org/crac/pull/46


More information about the crac-dev mailing list