-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filebeat rollback error on unattended installation #1736
Comments
Just want to report the same case, when filebeat installation failed, no rollback is performed.
|
Update reportThe problem is that rollbacks are generally performed in controlled situations, through some validation. |
After a little more research, I found another problem, in addition to the one stated above, which occurs in the following situation: if verbose mode is set, this causes the debug variable to contain the following value: This produces that in the following command: The result of the said command, even if it fails, returns a 0.
The output of these commands is:
As you can see, the eval returned a 0 as status, which the This was clarified, since the first intention of implementing a try-catch, this situation caused me problems. Script:
Output:
The possibility of implementing this logic will be discussed with the team. |
Update reportGenerate a try-catch implementation on the branch: Summarizing: Inside the filebeat_configure function, it fails on: One possibility in the face of this error is that in the previous step the template.json could not be downloaded for some reason: Anyway, I couldn't reproduce the mentioned error, because the previous command shouldn't throw an error since the errors are being redirected to the log file. However, any type of unexpected error could produce this situation, where the script fails, and continues with its execution. So the proposal would be to implement a try-catch block so that if it fails due to an unexpected error, print said error and then perform the rollback.
The idea is to add this type of validation in each step of the different types of installations (AIO, Distributed, etc.) The definition of the try catch was done with shopt and expand_aliases:
TestThe error was forced in the same command as the one reported, and two installation scripts were generated, one with the improvement and the other is the current one.
As seen in the second execution with the script that contains the improvement, the execution of the rollback occurred immediately after the failure. |
Update reportAfter several tests I found a situation: The problem with this command is that when grep does not match a value, the status returned to the script is a status 1 error, but it does not cause the script to fail. As an example:
As seen in the example, the grep that searches for the zip return a status of 0. But the grep that searches for a component not installed returns a status of 1. Tests:
After resolving this situation, try-catch was implemented for all types of installations. Another issue to keep in mind is how an error redirection is being used in this way: Test forcing error without verbose:
Test forcing error with verbose:
Test finish ok:
|
Hello,
The Filebeat module installation doesn't perform rollback when some conditions are met.
We have to review the trace error and try to reproduce and fix such error.
@havidarou reported this issue.
The text was updated successfully, but these errors were encountered: