Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> writes: >> >>> On Wed, 2009-03-18 at 13:03 -0700, Mike Waychison wrote: >>>> Polluting the dmesg buffer with messages from common failures (consider >>>> a multi-user cluster where checkpoints may or may not succeed) isn't >>>> very useful. >>> Yeah, I've already gotten an earful from Serge and Dan S. about this. :) >>> >>> Serge suggested that, perhaps, the audit framework could be used. We >>> might also use an ftrace buffer if we want to keep a whole ton of >>> messages around, too. >>> >>> dmesg is definitely not workable long-term at all. >> How about having place holder objects in the generated checkpoint. >> Then instead of having a failure you have a non-restoreable checkpoint. >> But you know which fd, or which mmaped region, or which other thing >> is causing the problem and if you want more information you can >> look at that resource. >> >> That gives user space the freedom and scrub out the non-checkpointable >> bits and replace them with something like /dev/null so that we can >> continue on and restore the checkpoint anyway, if we think our >> app can cope with some things going away. >> >> Eric > > I like this idea. yes. This is something required to replace stdios for example, when you execute an application under ssh, checkpoint and then restart on an other host. This a topical scenario for a batch manager in an HPC environment. identified resources of the container are tracked to be ignored by checkpoint and to be replaced by similar ones at restart. C. > Subystems which are temporarily entirely unsupported (like sysvipc) > would need at least a dummy section in the format wherein we can at > least say 'unsupported', otherwise we'll still just get a meaningless > -EINVAL. > > I actually got bitten yesterday by trying to checkpoint a task that > wasn't frozen. I forgot v14 had that check, and my failures (a > segfault actually) weren't helpful. > > -serge > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
