Restore checkpoint fails if stop/start app container with verbosegc log

[tam512]

I have an Open Liberty application container that has the following jvm.options.

# cat jvm.options
-verbose:gc
-Xdump:heap
-Xaggressive
-Xverbosegclog:/logs/verbosegc.log,200,10000

If I stop and start the app container, I see the following checkpoint restore failure

CWWKE0957I: Restoring the checkpoint server process failed. Check the /logs/checkpoint/restore.log log to determine why the checkpoint process was not restored. Launching the server without using the checkpoint image. 

The /logs/checkpoint/restore.log shows the following errors

# podman exec -it microwebapp-restore-app cat /logs/checkpoint/restore.log
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
Error (criu/libnetlink.c:84): Can't send request message: Permission denied
   134: Error (criu/files-reg.c:1994): File logs/verbosegc.log.001 has bad size 294611 (expect 250035)
   134: Error (criu/files.c:1200): Unable to open fd=3 id=0x3d
Error (criu/cr-restore.c:1494): 134 exited, status=1
Error (criu/cr-restore.c:2516): Restoring FAILED.

[RSalman]

Files opened by Verbose GC must be excluded from the CRIU dump. Opened logs can be problematic as the restore file validation can fail if the log changes in any way between checkpoint and restore. e.g. file contents/metadata changed or file not available at restore time.

This issue will be resolved by #16473