#2984 Issue closed: Automatic re-run disk creation shouldn't run forever

Labels: enhancement, discuss / RFC, fixed / solved / done

schlomo opened issue at 2023-05-10 07:14:

Currently the disk creation loop tries forever to re-run:
image

I'd like to suggest giving this a failure counter, so that it will abort if it is not successful after 3 attempts. This would help a lot with unattended recoveries and #2979 - even without adding a new parameter to rear.

As I don't know if there are indeed use cases where hammering the system with the same re-creation script would be successful I want to discuss this change here first.

Specifically the code in https://github.com/rear/rear/blob/db9302e8b37890bfcf4debf443da38652f147116/usr/share/rear/layout/recreate/default/200_run_layout_code.sh#L201-L202 should be changed to have a counter instead of while true; do and the default answer of "re-run disk creation".

Another approach would be changing the default choice here to Abort instead of trying again.

Can somebody please provide more context on the decision to just retry the disk creation?

jsmeix commented at 2023-05-10 08:23:

I think the current endless retries are there
to stay backward compatible with how it behaved before, see in
https://github.com/rear/rear/commit/e5d7f694212912d958168ec1238ed1bae25a50d2
the code of the renamed/deleted script
usr/share/rear/layout/recreate/default/200_run_script.sh
that was used before - click on "Load diff" at
https://github.com/rear/rear/commit/e5d7f694212912d958168ec1238ed1bae25a50d2#diff-5b4aeb76ebae763cb68af6e0bbd2e7d61ef40aebe6cad2aa8b01697d2cbf5ea6

What you need to do for an unattended use case is
to prepare for it, cf.
https://github.com/rear/rear/pull/2979#issuecomment-1534768715

In this particular case set USER_INPUT_LAYOUT_CODE_RUN appropriately,
see the section about "UserInput function default behaviour"
in default.conf

jsmeix commented at 2023-05-11 06:30:

@schlomo
regardless that now via
https://github.com/rear/rear/pull/2979
a generic way is implemented (which is good)
I would still like to understand what the reason is
why it is not possible (not at all or not in practice)
to prepare for an unattended use case via appropriate
settings of some USER_INPUT_... config variables
at least for a specific unattended use case?

E.g. in
https://github.com/rear/rear/pull/2979#issuecomment-1535350129
I read
"the user must know all possible inputs before".
This is true but for a specific unattended use case
it should be possible with reasonable effort to find out
which UserInput calls are relevant (e.g. run it as a test
and note what UserInput calls happened).

And in
https://github.com/rear/rear/pull/2979#issuecomment-1542204564
I read
"--non-interactive flag ... without changing the configuration files".
But one can already change configuration values via a
command line option by using e.g. '-C unattended.conf'
where etc/rear/unattended.conf contains configuration values
as needed for a specific unattended use case.

In the end what I like to understand is the reason why
it is not possible to get things working as needed
with what ReaR provides currently?
At least a test with current ReaR for a specific use case
and when that fails a report what had failed.
Was such a test done and if yes what was the result?

Bottom line:
Regardless that I agree with the implementation method in
https://github.com/rear/rear/pull/2979#issuecomment-1542195362
I still do not understand the reason behind why
https://github.com/rear/rear/pull/2979
is a "must have".

schlomo commented at 2023-06-02 08:25:

Resolved via #2988

[Export of Github issue for rear/rear.]