[SERVER-41138] "file-rename: MoveFileExW: Access is denied." leads to Fatal Assertion 28558 on 3.4.20 Created: 14/May/19  Updated: 20/May/19  Resolved: 20/May/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Sanjay Kumar Assignee: Eric Sedor
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MongoDB_LOGS.txt    
Operating System: ALL
Steps To Reproduce:

Can some one tell me how to fix

Participants:

 Description   

Have 3 mongo DB servers on 3.4.20 with replicaset in place

we are seeing fatal assertion 28558 at src\mongo\db\storage\wiredtiger\wiredtiger_util.cpp 365. 

We got this product as part of BMC Remedy 9.1.0.4 SP2

How to fix this error! why is this error generated!  Is there a stable product from Mongo which is compatible with Smart IT Remedy 2.00.001



 Comments   
Comment by Eric Sedor [ 20/May/19 ]

Unfortunately without a clear method of reproduction we aren't able to investigate further at this time. We do continue to recommend following up on the possibility that something is accessing database files in your environment, particularly around what changed when you changed versions of the BMC Package you mentioned.

Comment by Sanjay Kumar [ 15/May/19 ]

There is no previous configuration to revert to. I am bit surprised the core functionality is choking on all the version of mongo implementation, and have seen on mongo community as well, so thought its a server support project - If not kindly propagate this issue to concerned group.

There are no antivirus or no configuration changes since deployment except a tag as authorized is enabled

Get Outlook for iOS<https://aka.ms/o0ukef>

Comment by Eric Sedor [ 15/May/19 ]

This error usually indicates that another process is accessing files critical to mongod, which we strongly recommend against. This is not limited to antivirus software. Unfortunately our ability to diagnose this as a potential bug will be limited unless you have the ability to provide specific reproduction steps. Does this make sense?

We recommend reverting to your earlier configuration if you are urgently concerned about the overall availability of your deployment.

To set expectations: This SERVER project is for reporting and investigating bug reports and feature suggestions for the MongoDB core server. It is not the best place to obtain urgent support for production environments.

Comment by Sanjay Kumar [ 15/May/19 ]

Any update Eric!

Comment by Sanjay Kumar [ 15/May/19 ]

I confirm we are running 3.4.20 on all 3 MongoDB nodes.   No antivirus software accessing WT file

Comment by Eric Sedor [ 15/May/19 ]

sanjay2019, the issue seems similar to WT-3962 which was backported to 3.4.14. Can you confirm the impacted nodes are indeed running 3.4.20?

Can you also confirm that no other processes (such as antivirus software) are accessing the WiredTiger.turtle file?

Comment by Sanjay Kumar [ 15/May/19 ]

Just now we saw another server in production having FATAL Assertion issue..  Let me know how to resolve before we have outage due to the product!!!

Comment by Sanjay Kumar [ 15/May/19 ]

Any update Eric?

Comment by Sanjay Kumar [ 14/May/19 ]

Here you go Eric - I appreciate for your quick response.  Please find mongoDB_logs.txt attached for your references.

 

 

Comment by Eric Sedor [ 14/May/19 ]

Hi sanjay2019, can you please provide the mongod log files preceding the fatal assertion? We'd like to see additional context about the error.

Comment by Sanjay Kumar [ 14/May/19 ]

Originally, BMC Package came with 3.4.2 Mongo for Smart IT 1.6, we upgraded smart it to 2.0.00.1 and mongo to 3.4.20 (BMC recommended to be on 3.4.9.x) - we went even higher.  The issue persists in Production today!  we are windows server 2012 64bit!

Any recommendations to resolve would be great.  Not workaround a fix! or a stable product which is compatible with BMC Smart IT 2.0.001 

Generated at Thu Feb 08 04:56:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.