Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Criu-ns restore fails with error: Failed to set group 1 on 0: Inappropriate ioctl for device #1893

Closed
Niteesh26 opened this issue May 17, 2022 · 3 comments · Fixed by #1922
Closed

Criu-ns restore fails with error: Failed to set group 1 on 0: Inappropriate ioctl for device #1893

Niteesh26 opened this issue May 17, 2022 · 3 comments · Fixed by #1922
Assignees
@Snorch
Labels
stale-issue

Comments

@Niteesh26
Copy link

Description

criu-ns dump works properly as .img files are created in the CRIU folder.
criu-ns restore fails to restore the process with the error:
Failed to set group 1 on 0: Inappropriate ioctl for device

Steps to reproduce the issue:

  1. Run a simple counter program.
  2. Dump the said program using criu-ns script:

./criu-ns dump -D /data/CRIU/ -v3 --shell-job -t 189026

  1. Try to restore the program using criu-ns script:

./criu-ns restore -D /data/CRIU/ --shell-job -v3

Describe the results you received:
Failed to set group 1 on 0: Inappropriate ioctl for device

Describe the results you expected:
Restore completed successfully

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

CRIU logs and information:

CRIU full dump/restore logs: 

(00.000415) Reading image tree
(00.000478) Add mnt ns 5 pid 189026
(00.000492) Add net ns 2 pid 189026
(00.000513) Migrating process tree (GID 189026->1 SID 188880->1)
(00.000527) Will restore in 0 namespaces
(00.000564) Collecting 37/54 (flags 2)
(00.000627) Collected [data/local/AMF/niteesh/criu-checkpoint/a.out] ID 0x1
(00.000645) Collected [usr/lib64/libc-2.17.so] ID 0x2
(00.000656) Collected [usr/lib64/libgcc_s-4.8.5-20150702.so.1] ID 0x3
(00.000664) Collected [usr/lib64/libm-2.17.so] ID 0x4
(00.000674) Collected [usr/lib64/libstdc++.so.6.0.19] ID 0x5
(00.000683) Collected [usr/lib64/ld-2.17.so] ID 0x6
(00.000696) Collected [dev/pts/6] ID 0x8
(00.000720) Collected [data/local/AMF/niteesh/criu-checkpoint] ID 0x9
(00.000749) Collected [.] ID 0xa
(00.000773) Collecting 43/59 (flags 0)
(00.000787) No remap-fpath.img image
(00.001041) cg: Preparing cgroups yard (cgroups restore mode 0x4)
(00.001380) cg: Determined cgroup dir blkio/user.slice already exist
(00.001397) cg: Skip restoring properties on cgroup dir blkio/user.slice
(00.001542) cg: Determined cgroup dir cpuset/ already exist
(00.001555) cg: Skip restoring properties on cgroup dir cpuset/
(00.001575) cg: Determined cgroup dir cpuset//docker already exist
(00.001584) cg: Skip restoring properties on cgroup dir cpuset//docker
(00.001607) cg: Determined cgroup dir cpuset//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9 already exist
(00.001618) cg: Skip restoring properties on cgroup dir cpuset//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9
(00.001640) cg: Determined cgroup dir cpuset//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0 already exist
(00.001649) cg: Skip restoring properties on cgroup dir cpuset//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0
(00.001669) cg: Determined cgroup dir cpuset//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2 already exist
(00.001682) cg: Skip restoring properties on cgroup dir cpuset//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2
(00.001821) cg: Determined cgroup dir devices/user.slice already exist
(00.001833) cg: Skip restoring properties on cgroup dir devices/user.slice
(00.001979) cg: Determined cgroup dir hugetlb/ already exist
(00.001991) cg: Skip restoring properties on cgroup dir hugetlb/
(00.002014) cg: Determined cgroup dir hugetlb//docker already exist
(00.002023) cg: Skip restoring properties on cgroup dir hugetlb//docker
(00.002043) cg: Determined cgroup dir hugetlb//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9 already exist
(00.002056) cg: Skip restoring properties on cgroup dir hugetlb//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9
(00.002074) cg: Determined cgroup dir hugetlb//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0 already exist
(00.002089) cg: Skip restoring properties on cgroup dir hugetlb//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0
(00.002111) cg: Determined cgroup dir hugetlb//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2 already exist
(00.002120) cg: Skip restoring properties on cgroup dir hugetlb//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2
(00.002277) cg: Determined cgroup dir memory/user.slice already exist
(00.002289) cg: Skip restoring properties on cgroup dir memory/user.slice
(00.002433) cg: Determined cgroup dir perf_event/ already exist
(00.002445) cg: Skip restoring properties on cgroup dir perf_event/
(00.002467) cg: Determined cgroup dir perf_event//docker already exist
(00.002476) cg: Skip restoring properties on cgroup dir perf_event//docker
(00.002496) cg: Determined cgroup dir perf_event//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9 already exist
(00.002508) cg: Skip restoring properties on cgroup dir perf_event//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9
(00.002526) cg: Determined cgroup dir perf_event//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0 already exist
(00.002540) cg: Skip restoring properties on cgroup dir perf_event//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0
(00.002559) cg: Determined cgroup dir perf_event//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2 already exist
(00.002573) cg: Skip restoring properties on cgroup dir perf_event//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2
(00.002709) cg: Determined cgroup dir freezer/ already exist
(00.002721) cg: Skip restoring properties on cgroup dir freezer/
(00.002742) cg: Determined cgroup dir freezer//docker already exist
(00.002755) cg: Skip restoring properties on cgroup dir freezer//docker
(00.002782) cg: Determined cgroup dir freezer//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9 already exist
(00.002791) cg: Skip restoring properties on cgroup dir freezer//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9
(00.002815) cg: Determined cgroup dir freezer//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0 already exist
(00.002824) cg: Skip restoring properties on cgroup dir freezer//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0
(00.002843) cg: Determined cgroup dir freezer//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2 already exist
(00.002856) cg: Skip restoring properties on cgroup dir freezer//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2
(00.002999) cg: Determined cgroup dir net_prio,net_cls/ already exist
(00.003011) cg: Skip restoring properties on cgroup dir net_prio,net_cls/
(00.003033) cg: Determined cgroup dir net_prio,net_cls//docker already exist
(00.003042) cg: Skip restoring properties on cgroup dir net_prio,net_cls//docker
(00.003064) cg: Determined cgroup dir net_prio,net_cls//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9 already exist
(00.003077) cg: Skip restoring properties on cgroup dir net_prio,net_cls//docker/7ee6d46aa62ca1cd519582eea3c1b03c95e273d4b5b8414cb8354ee37403faa9
(00.003095) cg: Determined cgroup dir net_prio,net_cls//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0 already exist
(00.003110) cg: Skip restoring properties on cgroup dir net_prio,net_cls//docker/eca7981cb4571ac36bdd824d5f479af0cad48aff6b3b53b526a6193bd0080df0
(00.003129) cg: Determined cgroup dir net_prio,net_cls//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2 already exist
(00.003141) cg: Skip restoring properties on cgroup dir net_prio,net_cls//docker/47e60abb728d5e4cccfef79b07bd4bc32a9ad7bba7e8ef8a3d1a8edd8020a7b2
(00.003281) cg: Determined cgroup dir cpuacct,cpu/user.slice already exist
(00.003293) cg: Skip restoring properties on cgroup dir cpuacct,cpu/user.slice
(00.003431) cg: Determined cgroup dir pids/user.slice already exist
(00.003443) cg: Skip restoring properties on cgroup dir pids/user.slice
(00.003596) cg: Determined cgroup dir systemd/user.slice/user-4900.slice/session-37328.scope already exist
(00.003609) cg: Skip restoring properties on cgroup dir systemd/user.slice/user-4900.slice/session-37328.scope
(00.003712) No mountpoints-5.img image
(00.003814) Forking task with 189026 pid (flags 0x0)
(00.012859) 189026: cg: Move into 2
(00.013177) 189026: Calling restore_sid() for init
(00.013209) 189026: Collecting 41/37 (flags 2)
(00.013362) 189026: tty: Collected tty ID 0x7 (pts)
(00.013407) 189026: Collecting 42/51 (flags 0)
(00.013419) 189026: No tty-data.img image
(00.013425) 189026: Restoring namespaces 189026 flags 0x0
(00.013446) 189026: Preparing info about shared resources
(00.013462) 189026: No seccomp.img image
(00.013468) 189026: Collecting 45/38 (flags 0)
(00.013477) 189026: No filelocks.img image
(00.013483) 189026: Collecting 39/27 (flags 0)
(00.013492) 189026: No pipes-data.img image
(00.013498) 189026: Collecting 40/27 (flags 0)
(00.013507) 189026: No fifo-data.img image
(00.013513) 189026: Collecting 38/60 (flags 0)
(00.013522) 189026: No sk-queues.img image
(00.013676) 189026: vma 0x400000 0x401000
(00.013685) 189026: vma 0x600000 0x601000
(00.013691) 189026: vma 0x601000 0x602000
(00.013696) 189026: vma 0x7fb6e083b000 0x7fb6e09fe000
(00.013702) 189026: vma 0x7fb6e09fe000 0x7fb6e0bfe000
(00.013708) 189026: vma 0x7fb6e0bfe000 0x7fb6e0c02000
(00.013713) 189026: vma 0x7fb6e0c02000 0x7fb6e0c04000
(00.013719) 189026: vma 0x7fb6e0c04000 0x7fb6e0c09000
(00.013725) 189026: vma 0x7fb6e0c09000 0x7fb6e0c1e000
(00.013730) 189026: vma 0x7fb6e0c1e000 0x7fb6e0e1d000
(00.013736) 189026: vma 0x7fb6e0e1d000 0x7fb6e0e1e000
(00.013742) 189026: vma 0x7fb6e0e1e000 0x7fb6e0e1f000
(00.013748) 189026: vma 0x7fb6e0e1f000 0x7fb6e0f20000
(00.013753) 189026: vma 0x7fb6e0f20000 0x7fb6e111f000
(00.013759) 189026: vma 0x7fb6e111f000 0x7fb6e1120000
(00.013765) 189026: vma 0x7fb6e1120000 0x7fb6e1121000
(00.013770) 189026: vma 0x7fb6e1121000 0x7fb6e120a000
(00.013775) 189026: vma 0x7fb6e120a000 0x7fb6e1409000
(00.013781) 189026: vma 0x7fb6e1409000 0x7fb6e1411000
(00.013786) 189026: vma 0x7fb6e1411000 0x7fb6e1413000
(00.013791) 189026: vma 0x7fb6e1413000 0x7fb6e1428000
(00.013800) 189026: vma 0x7fb6e1428000 0x7fb6e144a000
(00.013806) 189026: vma 0x7fb6e161c000 0x7fb6e1621000
(00.013811) 189026: vma 0x7fb6e1647000 0x7fb6e1649000
(00.013817) 189026: vma 0x7fb6e1649000 0x7fb6e164a000
(00.013822) 189026: vma 0x7fb6e164a000 0x7fb6e164b000
(00.013828) 189026: vma 0x7fb6e164b000 0x7fb6e164c000
(00.013834) 189026: vma 0x7fff37474000 0x7fff37495000
(00.013839) 189026: vma 0x7fff375d4000 0x7fff375d6000
(00.013844) 189026: vma 0xffffffffff600000 0xffffffffff601000
(00.013877) 189026: Collect fdinfo pid=189026 fd=0 id=0x7
(00.013903) 189026: Collect fdinfo pid=189026 fd=1 id=0x7
(00.013910) 189026: Collect fdinfo pid=189026 fd=2 id=0x7
(00.014032) 189026: Preparing SCMs
(00.014042) 189026: tty: Inherit terminal for id 0x7
(00.014048) 189026: tty: head driver pts id 0x7 index 6 (master 0 sid 188880 pgrp 189026 inherit 1)
(00.014066) 189026: File descs:
(00.014072) 189026:  `- type 1 ID 0x1
(00.014078) 189026:  `- type 1 ID 0x2
(00.014083) 189026:  `- type 1 ID 0x3
(00.014088) 189026:  `- type 1 ID 0x4
(00.014093) 189026:  `- type 1 ID 0x5
(00.014098) 189026:  `- type 1 ID 0x6
(00.014103) 189026:  `- type 11 ID 0x7
(00.014109) 189026:    `- FD 0 pid 189026
(00.014114) 189026:    `- FD 1 pid 189026
(00.014120) 189026:    `- FD 2 pid 189026
(00.014125) 189026:  `- type 1 ID 0x8
(00.014130) 189026:  `- type 1 ID 0x9
(00.014136) 189026:  `- type 1 ID 0xa
(00.020143) 189026: nr_restored_pages: 46
(00.020160) 189026: nr_shared_pages:   0
(00.020166) 189026: nr_dropped_pages:   0
(00.020171) 189026: nr_lazy:           0
(00.020186) 189026: Shrunk premap area to 0x7f0e92d0b000(0)
(00.020196) 189026: Restore on-core sigactions for 189026
(00.020274) 189026: Restoring children in alien sessions:
(00.020280) 189026: Restoring children in our session:
(00.020294) 189026: Restoring 189026 to 1 pgid
(00.020309) 189026: Restoring resources
(00.020328) 189026: Opening fdinfo-s
(00.020338) 189026: tty: open driver pts id 0x7 index 6 (master 0 sid 188880 pgrp 189026 inherit 1)
(00.020372) 189026: tty: Migrated slave peer 0x7 -> to fd 0
(00.020466) 189026: Error (criu/tty.c:684): tty: Failed to set group 1 on 0: Inappropriate ioctl for device
(00.020481) 189026: Error (criu/files.c:1194): Unable to open fd=0 id=0x7
(00.028021) Error (criu/cr-restore.c:1390): 189026 killed by signal 9: Killed
(00.028087) Error (criu/cr-restore.c:2266): Restoring FAILED.

Output of `criu --version`: 

Version: 3.9

Output of `criu check --all`: 


[prntb@lnx1108 ~]$ criu check --all
Can't check shutdown state of inet socket
Error (criu/cr-check.c:626): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP
Error (criu/cr-check.c:670): Dumping seccomp filters not supported: Input/output error
Error (criu/cr-check.c:889): cgroupns not supported. This is not fatal.
Warn  (criu/cr-check.c:1061): Do not have API to map vDSO - will use mremap() to restore vDSO
Warn  (criu/net.c:2770): Unable to get socket network namespace
Warn  (criu/cr-check.c:1027): compat_cr is not supported. Requires kernel >= v4.12
Looks good but some kernel features are missing
which, depending on your process tree, may cause
dump or restore failure.

Additional environment details:
@ashu-mehra
Copy link
Contributor

ashu-mehra commented May 30, 2022 •
edited
Loading

I am also facing same issue. Restore with criu-ns fails with this message:

(00.001456) 3214218: tty: open driver pts id 0x4 index 26 (master 0 sid 2630375 pgrp 3214218 inherit 1)
(00.001461) 3214218: tty: Migrated slave peer 0x4 -> to fd 0
(00.001472) 3214218: Error (criu/tty.c:689): tty: Failed to set group 3214218 on 0: Inappropriate ioctl for device
(00.001473) 3214218: Error (criu/files.c:1213): Unable to open fd=0 id=0x4
(00.001520) Error (criu/cr-restore.c:2536): Restoring FAILED.

@Snorch Snorch self-assigned this Jun 21, 2022
Snorch added a commit to Snorch/criu that referenced this issue Jun 22, 2022
@Snorch
criu-ns: capture controlling tty
2515260 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

checkpoint-restore#232 [1]

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Snorch added a commit to Snorch/criu that referenced this issue Jun 22, 2022
@Snorch
files-reg: skip failed mount lookup for shell-job's tty
c62ba50 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Snorch added a commit to Snorch/criu that referenced this issue Jun 22, 2022
@Snorch
criu-ns: capture controlling tty
289e883 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

checkpoint-restore#232 [1]

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Snorch added a commit to Snorch/criu that referenced this issue Jun 22, 2022
@Snorch
files-reg: skip failed mount lookup for shell-job's tty
e35a72a 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
@Snorch Snorch mentioned this issue Jun 22, 2022
Merged
@Snorch
Copy link
Member

Snorch commented Jun 22, 2022

@Niteesh26 @ashu-mehra Please try the fix from #1922, at least it helps for me to c/r simple sleep inf via criu-ns successfully:

# Term 1
sleep inf

# Term 2
mkdir -p /tmp/test-dump/dumpdir
cd /tmp/test-dump
criu-ns dump -D dumpdir -v4 -o dump.log --shell-job -t $(pgrep sleep)
['/usr/sbin/criu-ns', 'dump', '-D', 'dumpdir', '-v4', '-o', 'dump.log', '--shell-job', '-t', '40816']

criu-ns restore -D dumpdir -v4 -o restore.log --shell-job
['/usr/sbin/criu-ns', 'restore', '-D', 'dumpdir', '-v4', '-o', 'restore.log', '--shell-job']
...

# Term 3
mkdir -p /tmp/test-dump/dumpdir2
cd /tmp/test-dump
criu-ns dump -D dumpdir2 -v4 -o dump.log --shell-job -t $(pgrep sleep)
Replace pid 155482 with 40816
['/usr/sbin/criu-ns', 'dump', '-D', 'dumpdir2', '-v4', '-o', 'dump.log', '--shell-job', '-t', '40816']

criu-ns restore -D dumpdir2 -v4 -o restore.log --shell-job
['/usr/sbin/criu-ns', 'restore', '-D', 'dumpdir2', '-v4', '-o', 'restore.log', '--shell-job']
...

@Snorch Snorch mentioned this issue Jul 4, 2022
Open
Snorch added a commit to Snorch/criu that referenced this issue Jul 20, 2022
@Snorch
criu-ns: capture controlling tty
9ced3ed 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

checkpoint-restore#232 [1]

v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Snorch added a commit to Snorch/criu that referenced this issue Jul 20, 2022
@Snorch
files-reg: skip failed mount lookup for shell-job's tty
40360eb 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
@github-actions
Copy link

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

Snorch added a commit to Snorch/criu that referenced this issue Aug 14, 2022
@Snorch
criu-ns: capture controlling tty
2b336b0 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

checkpoint-restore#232 [1]

v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Snorch added a commit to Snorch/criu that referenced this issue Aug 14, 2022
@Snorch
files-reg: skip failed mount lookup for shell-job's tty
f1ada1f 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin pushed a commit that referenced this issue Aug 30, 2022
@Snorch @avagin
criu-ns: capture controlling tty
94bfff7 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

#232 [1]

v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.

Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin pushed a commit that referenced this issue Aug 30, 2022
@Snorch @avagin
files-reg: skip failed mount lookup for shell-job's tty
2666eec 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
@Snorch Snorch mentioned this issue Feb 24, 2023
Closed
avagin pushed a commit to avagin/criu that referenced this issue Mar 13, 2023
@Snorch @avagin
criu-ns: capture controlling tty
a177dd4 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

checkpoint-restore#232 [1]

v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin pushed a commit to avagin/criu that referenced this issue Mar 13, 2023
@Snorch @avagin
files-reg: skip failed mount lookup for shell-job's tty
c9d7ae5 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: checkpoint-restore#1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
@warusadura warusadura mentioned this issue Apr 10, 2023
Merged
avagin pushed a commit that referenced this issue Apr 16, 2023
@Snorch @avagin
criu-ns: capture controlling tty
9e91e62 
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].

But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).

So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.

Else when restoring first time via criu-ns (from criu-ns dump) we get:

Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device

#232 [1]

v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.

Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin pushed a commit that referenced this issue Apr 16, 2023
@Snorch @avagin
files-reg: skip failed mount lookup for shell-job's tty
2039d73 
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.

Else when dumping second time via criu-ns we get:

(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20

Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
@Snorch Snorch mentioned this issue Feb 2, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Snorch Snorch

Labels
stale-issue
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Criu ns tty fix Snorch/criu
3 participants
@Snorch @ashu-mehra @Niteesh26