3 ms·

SIGSTOP and SIGCONT are generic Unix signals. Where it gets more interesting is using elaborate checkpoint/restore [1] mechanisms for processes to serialize th

SIGSTOP and SIGCONT are generic Unix signals. Where it gets more interesting is using elaborate checkpoint/restore [1] mechanisms for processes to serialize their state (open fds, watches, IPC, etc.) into an image that can then be overlayed, remotely executed, debugged and so forth. [1] https://en.wikipedia.org/wiki/Application_checkpointing https://en.wikipedia.org/wiki/Application_checkpointing

derefr 11y ago
I've always thought this was a wrongheaded solution. I mean, of course, we have these apps that splay themselves all over global system resources in complex ways, and so we need to track down how they've done that, record it, and then replay it later to restore them. It's necessary. But imagine a well-behaved classical X11 app, running in something like a VM or Docker container. You execute its launcher, the VM spins up in the background, the app launches in the VM, and the app's X11 client connects to the X11 server you're staring at and displays things. If we truly want to sandbox apps, wouldn't it make more sense to move more toward a model like that—one where you have a discrete "application backend process" running in a sandbox, and you can just chuck around the sandbox itself willy-nilly (freezing it, thawing it, copying it, etc.) because it has well-defined connection-points to the host?
- vezzy-fnord 11y ago
  The purpose of C/R isn't sandboxing, it has nothing to do with it. It's about managing internal state and data structures from an external agent. C/R enables complete persistence by duplicating a process from its image, which can cut initialization and startup times by orders of magnitude, and resume service from an exact position with zero downtime, and not just basic mechanisms like socket superservers. It lets you back up process state at any arbitrary moment, send it over the network, recalculate and reexec immediately and then thaw again for debugging it from that particular point. It just helps enable live migrations and zero downtime recoordinations with far less complicated redundancy schemes. This includes containers. On top of it being a universal save/pause button. Depending on the robustness of the image format, it can be made space efficient through deduplication. C/R is quite invaluable for any scenario that involves fault tolerance, high response times, tracking down difficult bugs, low startup overhead and so on. I'm surprised why it's still such an obscure technique. Besides, I don't think the primary use case here is even graphical apps (not that they don't work just fine). What you really want is a local indexed copy of all the execution environment details, like pipes, sockets, timers, ttys, timers, sigmasks, *fds, etc. for infrastructure.

derefr 11y ago

I've always thought this was a wrongheaded solution. I mean, of course, we have these apps that splay themselves all over global system resources in complex ways, and so we need to track down how they've done that, record it, and then replay it later to restore them. It's necessary. But imagine a well-behaved classical X11 app, running in something like a VM or Docker container. You execute its launcher, the VM spins up in the background, the app launches in the VM, and the app's X11 client connects to the X11 server you're staring at and displays things. If we truly want to sandbox apps, wouldn't it make more sense to move more toward a model like that—one where you have a discrete "application backend process" running in a sandbox, and you can just chuck around the sandbox itself willy-nilly (freezing it, thawing it, copying it, etc.) because it has well-defined connection-points to the host?

vezzy-fnord 11y ago
The purpose of C/R isn't sandboxing, it has nothing to do with it. It's about managing internal state and data structures from an external agent. C/R enables complete persistence by duplicating a process from its image, which can cut initialization and startup times by orders of magnitude, and resume service from an exact position with zero downtime, and not just basic mechanisms like socket superservers. It lets you back up process state at any arbitrary moment, send it over the network, recalculate and reexec immediately and then thaw again for debugging it from that particular point. It just helps enable live migrations and zero downtime recoordinations with far less complicated redundancy schemes. This includes containers. On top of it being a universal save/pause button. Depending on the robustness of the image format, it can be made space efficient through deduplication. C/R is quite invaluable for any scenario that involves fault tolerance, high response times, tracking down difficult bugs, low startup overhead and so on. I'm surprised why it's still such an obscure technique. Besides, I don't think the primary use case here is even graphical apps (not that they don't work just fine). What you really want is a local indexed copy of all the execution environment details, like pipes, sockets, timers, ttys, timers, sigmasks, *fds, etc. for infrastructure.