[CRIU] [PATCH v5 2/3] Do not error out in RPC mode with wrong config file entries

[Radostin Stoyanov]

On 28/12/2018 22:41, Andrei Vagin wrote:
> On Thu, Dec 27, 2018 at 02:07:56PM +0000, Radostin Stoyanov wrote:
>> On 26/12/2018 21:42, Andrei Vagin wrote:
>>>> Relates: https://github.com/checkpoint-restore/criu/issues/578
>>>>
>>>> If the config parser finds a unknown option in the configuration file,
>>>> the wrong option is printed out and CRIU exits.
>>>>
>>>> In RPC mode this is not the best thing to do, as CRIU might not be able
>>>> to print the message to the user.
>>> It is a bad explanation, because with your first patch the user will see
>>> errors. I am not sure why we need to ignore unknown options in config
>>> files. It looks dangerous, because the user can do a typo and will not
>>> notice it.
>>>
>> A user could make a typo and they should be able to notice it in the log
>> file but
>> if CRIU exits with an error, this will break the checkpoint/restore
>> functionality of
>> container engines.
>>
>> An example of a software that has such behaviour is sshd. If a user
>> makes a typo in
>> the /etc/ssh/sshd_config file, after "systemctl restart sshd", they will
>> no longer be
>> able to connect via ssh. Although, for security reasons, the behaviour
>> of sshd
>> might be appropriate, I think that in the case of CRIU, showing a
>> message, instead
>> of exiting with an error, would be more user-friendly.
> Yes and no. I understand the sshd reasons, but they can be applied to
> criu restore, but not to criu dump, IMHO.
>
> Our goal is to not loose states of processes:
> 1. criu dump doesn't have to be destructive:
>   * in case of any error, processes have to continue running
>   * it is better to fail rather than dump wrong or incomplete state
>
> 2. sometimes we really may want to restore processes even if there is
> some problem
That is a very good point, I agree with you.

Is it OK to close https://github.com/checkpoint-restore/criu/issues/578
with the explanation above?

Thanks,
Radostin