[SERVER-20773] core/fsync.js can leave test server fsyncLocked Created: 06/Oct/15 Updated: 06/Dec/22 Resolved: 19/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | stm | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Tooling & Methods
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
If jstests/core/fsync.js throws an assertion after calling fsyncLock, but before calling fsyncUnlock, the server will be left in an fsyncLocked state. This can be a problem if multiple tests are being run in parallel, or --continueOnFailure is being used (resmoke will get stuck waiting for the fsyncLocked mongod). The exception to this is asserting if the fsyncLock has failed. This is safe as long as the server wasn't already fsyncLocked when fsyncLock was called (ie. testing recursive fsyncLock). Many of the tests have the kind of form you would expect:
Better would be to rearrange things so as to never call assert() between fsyncLock/fsyncUnlock, eg:
The main alternative to this approach would be to pass a "finally" function to assert(), which is called just before doassert(). But this would be more invasive (and probably uglier) than just fixing this one jstest. |
| Comments |
| Comment by Brooke Miller [ 19/Nov/21 ] | |||||||||||||||
|
We'd like this to be addressed in individual tests, rather than by Resmoke. Closing as Won't Fix as a result. | |||||||||||||||
| Comment by Kevin Pulo [ 07/Oct/15 ] | |||||||||||||||
|
Grepping reveals some other tests which could suffer from the same problem:
After inspection, there are three categories:
|