-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[CI] Race between FileUserRolesStore and disk cleanup #44006
Labels
:Security/Security
Security issues without another label
Team:Security
Meta label for security team
>test-failure
Triaged test failures from CI
Comments
Pinging @elastic/es-security |
It looks like this failed again for the same reason:
|
It's been 3 years without any additional comments and I can not find any evidence of this failing within the past 30 days (due to the reasons listed here, only a couple non-related general cluster health related failures). Closing this issue, nothing to un-mute since (except for #44609) this test has remained un-muted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
:Security/Security
Security issues without another label
Team:Security
Meta label for security team
>test-failure
Triaged test failures from CI
An
@After
method doing post test cleanup failed in https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-unix-compatibility/os=oraclelinux-7/103/consoleThe relevant part of the log file is this:
It tried to delete the directory
.../tempDir-003/config
but could not because the directory wasn't empty.Presumably it wasn't empty because
FileUserRolesStore
had just written.../tempDir-003/config/users_roles
into it. This is done by writing a temporary file, then renaming it to the eventual path. So it could easily confuse a recursive directory deletion routine running at the same time. The recursive directory deletion probably did successfully delete the previous version of theusers_roles
file.Maybe
FileUserRolesStore
needs to register itself withNode
so thatNode
can wait for it to complete during its shutdown sequence?This failure has only occurred once as far as I can see, so we don't necessarily need to rush to fix it. But I wanted to log an issue so that if it starts happening frequently there's something to reference with the investigation I've done so far.
The text was updated successfully, but these errors were encountered: