-
Notifications
You must be signed in to change notification settings - Fork 110
Issue 6229 - After an initial failure, subsequent online backups fail #6230
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
Conversation
936284b to
9875301
Compare
|
Increased the precision of the timestamp used to generate task CN: With one second precision the CI test is randomly failing because of task DN collision. |
|
Looks like there is another race condition: |
|
Looks like I did not fix the right place: it is the same task name conflict issue (and I do not see subsecond in task CN) |
5f93d75 to
8739d37
Compare
|
Test is still failing. now I think it is related to private tmp will change the temporary directoty |
4da66d8 to
0ccd43b
Compare
|
Have to retry the first backup in loop until it fails (sometime it does not) |
droideck
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Concerns are minor and ignorable if you'd like.
|
Fixed @droideck remarks. |
…#6230) * Issue 6229 - After an initial failure, subsequent online backups will not work Several issues related to backup task error handling: Backends stay busy after the failure Exit code is 0 in some cases Crash if failing to open the backup directory And a more general one: lib389 Task DN collision Solutions: Always reset the busy flags that have been set Ensure that 0 is not returned in error case Avoid closing NULL directory descriptor Use a timestamp having milliseconds precision to create the task DN Issue: #6229 Reviewed by: @droideck (Thanks!) (cherry picked from commit 04a0b6a)
…#6230) * Issue 6229 - After an initial failure, subsequent online backups will not work Several issues related to backup task error handling: Backends stay busy after the failure Exit code is 0 in some cases Crash if failing to open the backup directory And a more general one: lib389 Task DN collision Solutions: Always reset the busy flags that have been set Ensure that 0 is not returned in error case Avoid closing NULL directory descriptor Use a timestamp having milliseconds precision to create the task DN Issue: #6229 Reviewed by: @droideck (Thanks!) (cherry picked from commit 04a0b6a)
…#6230) * Issue 6229 - After an initial failure, subsequent online backups will not work Several issues related to backup task error handling: Backends stay busy after the failure Exit code is 0 in some cases Crash if failing to open the backup directory And a more general one: lib389 Task DN collision Solutions: Always reset the busy flags that have been set Ensure that 0 is not returned in error case Avoid closing NULL directory descriptor Use a timestamp having milliseconds precision to create the task DN Issue: #6229 Reviewed by: @droideck (Thanks!) (cherry picked from commit 04a0b6a)
…#6230) * Issue 6229 - After an initial failure, subsequent online backups will not work Several issues related to backup task error handling: Backends stay busy after the failure Exit code is 0 in some cases Crash if failing to open the backup directory And a more general one: lib389 Task DN collision Solutions: Always reset the busy flags that have been set Ensure that 0 is not returned in error case Avoid closing NULL directory descriptor Use a timestamp having milliseconds precision to create the task DN Issue: #6229 Reviewed by: @droideck (Thanks!) (cherry picked from commit 04a0b6a)
Several issues related to backup task error handling:
Backends stay busy after the failure
Exit code is 0 in some cases
Crash if failing to open the backup directory
And a more general one:
lib389 Task DN collision
Solutions:
Always reset the busy flags that have been set
Ensure that 0 is not returned in error case
Avoid closing NULL directory descriptor
Use a timestamp having milliseconds precision to create the task DN
Issue: #6229
Reviewed by: @droideck (Thanks!)