[CRIU] [PATCH 1/2] Quick patch for error when writing mem.lim default
Pavel Emelyanov
xemul at parallels.com
Fri Aug 15 12:25:09 PDT 2014
On 08/15/2014 11:15 PM, Serge Hallyn wrote:
> That's going to be a painful thing to do item-by-item. One way to address
> this - not urgent to do soon imo - would be to have the restart mark itself
> as failed, but not immediately halt; have it write outa a file with all of
> the absent features; Then the user edits that file marking all of the
> ok-to-ignore things, and passes it in with a '--ignore-absent <file>'
> argument, which criu then honors.
I like the idea to postpone the failure and ask the caller what to do.
How about pushing the list of not found properties into the "post-restore"
script letting it decide what to do next? Or even introduce yet another
one, e.g. "cgroup-restore".
> Just a thought, but it seems like the only sane way to handle it.
>
> Quoting Pavel Emelyanov (xemul at parallels.com):
>> On 08/15/2014 08:54 PM, Ying Han wrote:
>>> Ping?
>>
>> We all agreed to commit the change that makes _dumping_ of absent properties
>> non-fatal (I'll do that soon). As far as writing is concerned -- it looks like
>> just ignoring the absence of properties from image dumps is not good as generic
>> solution. Instead, for restore we need some fine-grained control over which
>> properties to restore and which to ignore.
>>
>> Thanks,
>> Pavel
>>
>>
>>>
>>>
>>> On Wed, Aug 13, 2014 at 11:59 AM, <gbellack at google.com <mailto:gbellack at google.com>> wrote:
>>>
>>> From: Garrison Bellack <gbellack at google.com <mailto:gbellack at google.com>>
>>>
>>> When writing the system default for memory.limit_in_bytes (which is a LLONG_MAX)
>>> the write fails. The number is equivalent to -1 (unlimited). So during dump,
>>> store the number -1 instead.
>>>
>>> Change-Id: Iafccc96bf5dbade763d7addaeda24194616e4d5f
>>> Signed-off-by: Garrison Bellack <gbellack at google.com <mailto:gbellack at google.com>>
>>> ---
>>> cgroup.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/cgroup.c b/cgroup.c
>>> index 7ac2dd8..f8dbbde 100644
>>> --- a/cgroup.c
>>> +++ b/cgroup.c
>>> @@ -288,6 +288,7 @@ static int read_cgroup_prop(struct cgroup_prop *property, const char *fpath)
>>> {
>>> char pbuf[PATH_MAX], buf[100];
>>> FILE *f;
>>> + char *endptr;
>>>
>>> if (snprintf(pbuf, PATH_MAX, "%s/%s", fpath, property->name) >= PATH_MAX) {
>>> pr_err("snprintf output was truncated");
>>> @@ -315,6 +316,14 @@ static int read_cgroup_prop(struct cgroup_prop *property, const char *fpath)
>>> return -1;
>>> }
>>>
>>> + if (strtoll(buf, &endptr, 10) == LLONG_MAX)
>>> + strcpy(buf, "-1");
>>> +
>>> + if (strcmp(endptr, "\n")) {
>>> + pr_perror("Failed parsing %s, with strtoll\n", buf);
>>> + return -1;
>>> + }
>>> +
>>> property->value = xstrdup(buf);
>>> if (!property->value)
>>> return -1;
>>> --
>>> 2.1.0.rc2.206.gedb03e5
>>>
>>> _______________________________________________
>>> CRIU mailing list
>>> CRIU at openvz.org <mailto:CRIU at openvz.org>
>>> https://lists.openvz.org/mailman/listinfo/criu
>>>
>>>
>>
>> _______________________________________________
>> CRIU mailing list
>> CRIU at openvz.org
>> https://lists.openvz.org/mailman/listinfo/criu
> .
>
More information about the CRIU
mailing list