Closed shmyer closed 1 month ago
If you are using containers, be aware that configuring capabilities may be required, see https://github.com/sdeleuze/spring-boot-crac-demo/blob/main/restore.sh for an example. Also you may want to ensure the path app-18.0.0-b002eaed.jar
does not change (which could be the case with volumes, etc.)
Is app-18.0.0-b002eaed.jar
the executable JAR of your Spring Boot app?
I am not in a container environment. I am on a Linux VM on a VMWare Host. Could capabilities still be an issue here? I am currently on a 4.12 Linux kernel, which does not have the CHECKPOINT_RESTORE capability yet. It seems like on older Linux kernels the capability SYS_ADMIN is the one required for checkpoint/restore. I am using a non-root user.
However, as far as I understood CRIU is nevertheless running as root, since one thing I had to let our sysadmins do was this here: https://docs.azul.com/core/crac/crac-debugging#failures-in-native-checkpoint-or-restore
sudo chown root:root /path/to/criu
sudo chmod u+s /path/to/criu
Without that it didn't get past the CRIU part of the restore. But according to my restore.log the CRIU part of the restore seems to be working now.
Yes, the file's location is the same during the creation of the checkpoint and during the restore. Yes, this Jar file is the executable JAR of my Spring Boot app.
Looks like more a JDK/CRaC level issue so not sure what we can do about it on Framework side, do you agree?
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
I guess you're right. In the end I've decided to abandon my plans to use CRaC. It doesn't seem mature enough to me.
Affects: 6.1.10 JDK: zulu21.34.19-ca-crac-jdk21.0.3-linux_x64 Running on a Linux VM
I am trying to use CRaC with a Spring Boot app. I have come across many issues so far, including logback appenders causing
jdk.crac.impl.CheckpointOpenFileException
upon checkpoint creation (https://github.com/spring-projects/spring-boot/issues/38548) and the Eureka Discovery Client causing an open connection because of fetching the registry before checkpoint. I was able to workaround those issues so far and I made the checkpointing work.Now I am stuck on the restore. As you can see in the attached log, the restore code is trying to load my Spring Boot Jar as a class and of course it can't find that. I don't quite understand why it does that.
I've also attached the CRIU dump and restore logs below, they seem fine to me, but I might be wrong.
Spring Boot Log:
CRIU Logs: dump4.log restore.log