C/R of program with output to both terminal and file

[oleotiger]

Description

I have a program which output log to both terminal and a log file. When I restore the first time and kill with ctrl+C, I get errors the second time to restore:

 46365: Error (criu/files-reg.c:2093): File data/cci/checkpoint/parest_imgs/log has bad size 284 (expect 248)
 46365: Error (criu/files.c:1213): Unable to open fd=3 id=0x9
Error (criu/cr-restore.c:2536): Restoring FAILED.
Error (criu/cr-restore.c:1498): 46365 killed by signal 9: Killed

This is due to changed log after restoring. I have to make a backup of the log file and when I want to restore, resume the log file first.

Q1 Any other good idea to resolve it ?

Q2 After I restore the program and kill it by Ctrl+C, enter does not work in my terminal(Mobaxterm). Enter should switch to new line but it keeps on the same line. e.g.:

[root@pod2p-arm-node169 2]# criu restore --images-dir  ./ -j
[root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]#

I think it is caused by the resume of the program. How to solve it?

Steps to reproduce the issue:

1. run program /home/speccpu_tuning/spec2017/benchspec/CPU/510.parest_r/exe/parest_r_base.gcc7.3.0-dynamic-Ofast-64 /home/speccpu_tuning/spec2017/benchspec/CPU/510.parest_r/data/refrate/input/ref.prm
2. checkpoint criu dump -t $(pgrep parest_r_base) --images-dir ./0 -j
3. restore and stop it with kill cp log.bak log && criu restore --images-dir ./0 -j and then kill with ctrl+c
4. type enter

Describe the results you received:

[root@pod2p-arm-node169 2]# criu restore --images-dir  ./ -j
[root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]# [root@pod2p-arm-node169 2]#

Additional information you deem important (e.g. issue happens only occasionally):

• OS CentOS Linux release 7.6.1810 (AltArch)
• Kernel 6.14.0-115.el7a.0.1.aarch64
• Arch: Arm64

Output of `criu --version`:

Version: 3.17.1

Output of `criu check --all`:

Warn  (criu/cr-check.c:813): Dirty tracking is OFF. Memory snapshot will not work.
Warn  (criu/cr-check.c:1242): Do not have API to map vDSO - will use mremap() to restore vDSO
Warn  (criu/cr-check.c:1231): clone3() with set_tid not supported
Error (criu/cr-check.c:1273): Time namespaces are not supported
Error (criu/cr-check.c:1283): IFLA_NEW_IFINDEX isn't supported
Warn  (criu/cr-check.c:1300): Pidfd store requires pidfd_open syscall which is not supported
Warn  (criu/cr-check.c:1334): Nftables based locking requires libnftables and set concatenations support
Warn  (criu/cr-check.c:804): ptrace(PTRACE_GET_RSEQ_CONFIGURATION) isn't supported. C/R of processes which are using rseq() won't work.
Warn  (criu/cr-check.c:1162): CRIU built without CONFIG_COMPAT - can't C/R compatible tasks
Looks good but some kernel features are missing
which, depending on your process tree, may cause
dump or restore failure.

Additional environment details:

[Snorch]

q2: @oleotiger With fix from https://github.com/checkpoint-restore/criu/pull/1922, I manage to make this simple example https://github.com/checkpoint-restore/criu/issues/1893#issuecomment-1162938507 working with criu-ns, and yes after restore ctrl+c works smoothly for me in this case. So you can probably try to reuse this example. q1: CRIU requires that the whole filesystem (or at least the files dumpee uses) is exactly the same on restore, so you should make snapshots of filesystem (or at least the files dumpee uses). There is no other way. Then process is run inside container and dumped with the whole container preserving filesystem would be a responce of container environment, so it may be easier to use containerized apps.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.