Info

Dear Support-Team, due to an software update for our data historian and visualisation application, we faced the problem that the installation process crashed and the update gone wrong. Since then we are unable to access the stored data and also can't write new data into database (of course because the service isn't running). I think we may restarted the server not properly (which also holds the MongoDB service) and so the mongod.lock file remained NOT empty. Deleting it didn't solve the problem. What can be done to get the MongoDB service running again? Attached please find all WiredTiger.* files such as sizeStorer.wt and *.lock files. Thanks in advance! Yours hopefully, Clemens Schadner cts GmbH

Top User Comments

ctsclemens commented on Fri, 4 Aug 2017 05:53:38 +0000: Hello Mark, later I started the command prompt as admin and could do a mongodump, but the data is somehow gone. Since this is not in a productive environment we don't essentially need the data. You can close the ticket. So thanks a lot for your time Mark and have a nice day! Mit freundlichen Grüßen / Best regards Clemens Schadner Software Engineer | Advanced Solutions cts GmbH Fuhrmannstraße 10 D-84508 Burgkirchen Tel. .+49 (0)8679 91689-202 Fax. .+49 (0)8679 91689-120 clemens.schadner@cts-gmbh.de www.group-cts.de Gesellschaft mit beschränkter Haftung Sitz der Gesellschaft: Burgkirchen a. d. Alz Handelsregister: Amtsgericht Traunstein, HRB16883 Geschäftsführer: Hans Gehringer, Robert Schüller mark.agarunov commented on Wed, 2 Aug 2017 15:41:02 +0000: Hello ctsClemens, Thank you for the information. Looking at the error output you provided, this looks like it may be a permissions issue. Are you starting mongodb as an administrator? The specific error is Access Denied, which would indicate that the user you are trying to start mongod as is not the same user, and does not have the same access as the user it was previously running as. Please try executing this command as an administrator and let me know if this fixes the issue. Thanks, Mark ctsclemens commented on Tue, 18 Jul 2017 07:30:41 +0000: Hey Mark, thanks for your quick response! The files provided by you didn't solve the problem - the damn service throws the same error 1067. When I try: C:\inmation.root\MongoDB\bin>mongod --repair --repairpath C:\inmation.root\MongoDB\data --dbpath C:\inmation.root\MongoDB\data --storageEngine wiredTiger --noauth 2017-07-18T07:05:32.850+0200 I STORAGE [initandlisten] exception in initAndListen: 98 Unable to create/open lock file: C:\inmation.root\MongoDB\data\mongod.lock errno:5 Access denied. Is a mongod instance already running?, terminating 2017-07-18T07:05:32.850+0200 I CONTROL [initandlisten] dbexit: rc: 100 But I'm pretty sure that no mongod is running. Please find the complete logs in the attachment. underlying storage mechanism: wiredTiger; The MongoDB runs on a VM with a local storage, its backup runs over the network to our NAS. Disk typ: SAS HDD; RAID: 5 Integrity: The VM containing the MongoDB runs in an productive environment. The IT guy told me he doesn't has enough resources to move all VMs to another server and smash those check commands into the console to check the disks. But the server is quite knew so everything should be fine (hopefully). Yes, the version didn't changed. I didn't manipulated the underlying db files, just made a software update for our application which uses MongoDB. I guess mongod was running, but in previous updates that wasn't a problem. No I never restored this instance from backups. We use Veeam Backup & Replication 9.5 to backup our VMs. What you are especially looking for doesn't really exist at our company (according to the IT guy). But our ESXi shows no errors and runs without any issues. Thanks for your time! Best regards, Clemens mark.agarunov commented on Mon, 17 Jul 2017 21:52:35 +0000: Hello ctsClemens, Thank you for the report. I've attached a repair attempt of the files you've provided. Would you please extract these files and replace them in your $dbpath and let us know if it resolves the issue? If you are still seeing errors after replacing these files, please provide the complete logs from mongod so that we can further investigate. Additionally, if this issue persists, please provide the following information: What kind of underlying storage mechanism are you using? Are the storage devices attached locally or over the network? Are the disks SSDs or HDDs? What kind of RAID and/or volume management system are you using? Would you please check the integrity of your disks? Has the database always been running this version of MongoDB? If not please describe the upgrade/downgrade cycles the database has been through. Have you manipulated (copied or moved) the underlying database files? If so, was mongod running? Have you ever restored this instance from backups? What method do you use to create backups? When was the underlying filesystem last checked and is it currently marked clean? Thanks, Mark

Steps to Reproduce