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

Adrian Reber adrian at lisas.de
Wed Jan 2 20:36:18 MSK 2019


On Wed, Jan 02, 2019 at 09:32:09AM -0800, Andrei Vagin wrote:
> On Fri, Dec 28, 2018 at 11:56:16PM +0000, Radostin Stoyanov wrote:
> > 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?
> 
> I would like to know what Adrian is thinking about this.

The whole series was just trying to help with Radostin's 'bug'. But if
nobody sees this as a problem we can drop the whole thing.

		Adrian


More information about the CRIU mailing list