[crac] RFR: Print better diagnostics for spawning CRIU [v2]

Jan Kratochvil jkratochvil at openjdk.org
Wed Aug 9 23:11:28 UTC 2023


On Wed, 9 Aug 2023 19:41:33 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - print error messages in C++
>>  - Merge branch 'crac' into crac-error
>>  - Print better diagnostics for spawning CRIU.
>
> src/java.base/unix/native/criuengine/criuengine.cpp line 199:
> 
>> 197:         if (WEXITSTATUS(status) != SUPPRESS_ERROR_IN_PARENT) {
>> 198:             std::cerr << "Spawned CRIU \"" << join_args(args) << "\" has not properly exited:"
>> 199:               " exit code " << WEXITSTATUS(status) << " - check " << path_abs(imagedir, log_local) << std::endl;
> 
> we are not required to abs(imagedir), as unprocessed that is in the same way as it was provided in the args

The problem is users do not execute `criuengine` themselves. From my experience:

$ $JTREG_HOME/bin/jtreg -jdk:$ZULU_HOME -v:all -timeout:10 $TEST_HOME/test/jdk/jdk/crac/BigCheckpointTest.java
Spawned CRIU "/home/azul/azul/crac-git/build/linux-x86_64-server-fastdebug/images/jdk/lib/criu dump -t 648896 -D cr --shell-job -v4 -o dump4.log" has not properly exited: exit code 1 - check dump4.log
$ ls -l dump4.log
ls: cannot access 'dump4.log': No such file or directory

How to find out `dump4.log` is hiding in the `JTwork/scratch_1/cr` subdirectory?

$ ls -l  ./JTwork/scratch_1/cr/dump4.log
-rw------- 1 azul azul 3547 Aug 10 06:58 ./JTwork/scratch_1/cr/dump4.log

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

PR Review Comment: https://git.openjdk.org/crac/pull/97#discussion_r1289340035


More information about the crac-dev mailing list