| kata-irc-bot | <jakob.naucke> @eric.ernst I currently have an installation that seems to do this reliably: 1. Create a super basic k8s pod. Kata shim, QEMU, virtiofsd start. 2. Delete that pod. QEMU quits, virtiofsd ceases to be a child of the Kata shim. `kubectl delete` does not return yet. 3. After some seconds (>10), `kubectl delete` returns and virtiofsd quits. Kata shim remains behind, has a corrupt stack according to GDB. When running a container with | 10:39 |
|---|---|---|
| kata-irc-bot | `ctr`, the shim also stays behind quite some time after QEMU quits, but ultimately terminates (or is terminated?). I might be able to find something with runtime analysis, but if this rings any bells, I'm glad to hear them :slightly_smiling_face: | 10:39 |
| kata-irc-bot | <jakob.naucke> Grrr, every interaction with the container just hangs when GDB is attached to the shim… | 11:03 |
| kata-irc-bot | <jakob.naucke> So I still have to figure out how to isolate this (esp. because delve is not supported on s390x), and if at all possible, I should try to reproduce this on a dev machine rather than our CI (which I'll bring back soon). For the time being, I have found out that this does not seem to occur with virtio-9p instead of virtio-fs, which also gives me some debugging hints. | 11:20 |
| kata-irc-bot | <gabriela.cervantes.te> for containerd `ctr` is there an equivalent like `docker cp`? | 20:53 |
| kata-irc-bot | <eric.ernst> I don't think so | 21:24 |
| kata-irc-bot | <eric.ernst> no, not at the CLI level | 21:27 |
| kata-irc-bot | <eric.ernst> Was looking, you *could* do something like: https://github.com/containerd/containerd/issues/2044#issuecomment-359893164 | 21:27 |
| kata-irc-bot | <eric.ernst> That would effectively be the same as doing a copy into the guest filesystem | 21:27 |
| kata-irc-bot | <gabriela.cervantes.te> ohh thanks let me take a look | 21:40 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!