Starting mongodb with plain backup of previous /data/db contents - mongodb

I'be grabbed all files from /data/db dir from other sever and now trying to start mongo with it on another one. Here are the files I have:
-rw------- 1 root root 1073741824 Feb 2 11:21 j._0
drwxr-xr-x 2 mongodb nogroup 4096 May 3 12:02 journal
-rw------- 1 root root 67108864 Feb 12 06:43 metadocs-node_db.0
-rw------- 1 root root 134217728 Jun 27 2012 metadocs-node_db.1
-rw------- 1 root root 16777216 Feb 12 06:43 metadocs-node_db.ns
-rwxr-xr-x 1 mongodb nogroup 0 May 3 12:02 mongod.lock
-rw------- 1 root root 1073741824 Aug 28 2012 prealloc.1
-rw------- 1 root root 1073741824 Aug 28 2012 prealloc.2
root#mtg:/var/lib/mongodb#
While starting, I get (from logfile /var/log/mongodb/mongodb.log):
Fri May 3 12:02:01 [initandlisten] options: { bind_ip: "127.0.0.1", config:
"/etc/mongodb.conf", dbpath: "/var/lib/mongodb",$
Fri May 3 12:02:01 [initandlisten] journal dir=/var/lib/mongodb/journal
Fri May 3 12:02:01 [initandlisten] recover : no journal files present, no recovery needed
Fri May 3 12:02:01 [initandlisten] couldn't open /var/lib/mongodb/_metadocs-node_db.ns errno:13 Permission denied
Fri May 3 12:02:01 [initandlisten] error couldn't open file /var/lib/mongodb/_metadocs-node_db.ns terminating
Fri May 3 12:02:01 dbexit:
I'm running
sudo service mongodb start
So, what I'm doing wrong? What files are missing for mongodb to start? Why I'm getting "Permission denied"? Working as root, BTW. No other instances of mongo is running. Thanks!

When starting MongoDB as a service, the packaged start script will start your mongod server under a MongoDB user. Looking at a MongoDB 2.4 init.d script for mongod shows the user as "mongod". When setting up data and log directories it is important that the MongoDB user has read/write access to the directories and files contained within.

Related

MongoDB data disappeared after kernal panic in Ubuntu

The DB disappeared after 2019-07-25T06:36:53.999+0900. Below is log file. I am just installing some ubuntu packages but there some problem like /boot foler disk space issues or not, the kernel disrupted and I tried to boot with recover mode, and then succeed it. But after booting, my mongodb data looks disappeared - If I access my website there should be some articles but I cannot find this articles - perhaps it disappeared.
What I did is ... In grup selection window when access to ubuntu recovery mode, I choose "clean" one time and it looks like excuting apt-get autoremove. After I realize data gone, I typed mongod --repair one time. This two thing are all I did. Ah, I update ubutu version 3 days ago. But that time the db has no problem.
Where is my DB? Can you guess? I don't have backups so I am very confused.
2019-07-25T06:36:53.902+0900 I NETWORK [listener] connection accepted from 127.0.0.1:35460 #1938 (9 connections now open)
2019-07-25T06:36:53.930+0900 I NETWORK [listener] connection accepted from 127.0.0.1:35461 #1939 (10 connections now open)
2019-07-25T06:36:53.950+0900 I NETWORK [listener] connection accepted from 127.0.0.1:35462 #1940 (11 connections now open)
2019-07-25T06:36:53.952+0900 I NETWORK [listener] connection accepted from 127.0.0.1:35463 #1941 (12 connections now open)
2019-07-25T06:36:53.999+0900 I NETWORK [conn1941] end connection 127.0.0.1:35463 (11 connections now open)
2019-07-25T06:36:53.999+0900 I NETWORK [conn1940] end connection 127.0.0.1:35462 (10 connections now open)
2019-07-25T06:36:53.999+0900 I NETWORK [conn1939] end connection 127.0.0.1:35461 (9 connections now open)
2019-07-25T06:36:53.999+0900 I NETWORK [conn1938] end connection 127.0.0.1:35460 (8 connections now open)
2019-07-26T01:03:53.557+0900 I CONTROL [main] ***** SERVER RESTARTED *****
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] MongoDB starting : pid=854 port=27017 dbpath=/var/lib/mongodb 64-bit host=ubuntu
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] db version v4.0.0
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] git version: 3b07af3d4f471ae89e8186d33bbb1d5259597d51
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] allocator: tcmalloc
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] modules: none
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] build environment:
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] distmod: ubuntu1404
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] distarch: x86_64
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] target_arch: x86_64
2019-07-26T01:03:53.747+0900 I CONTROL [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", port: 27017 }, processManagement: { timeZoneInfo: "/usr/share/zoneinfo" }, storage: { dbPath: "/var/lib/mongodb", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log" } }
2019-07-26T01:03:53.748+0900 W STORAGE [initandlisten] Detected unclean shutdown - /var/lib/mongodb/mongod.lock is not empty.
2019-07-26T01:03:53.750+0900 I STORAGE [initandlisten] Detected data files in /var/lib/mongodb created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-07-26T01:03:53.750+0900 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2019-07-26T01:03:53.750+0900 I STORAGE [initandlisten]
2019-07-26T01:03:53.750+0900 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-07-26T01:03:53.750+0900 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-07-26T01:03:53.750+0900 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-07-26T01:03:55.375+0900 I STORAGE [initandlisten] WiredTiger message [1564070635:375844][854:0x7f9600196a00], txn-recover: Main recovery loop: starting at 4/38038144
2019-07-26T01:03:55.376+0900 I STORAGE [initandlisten] WiredTiger message [1564070635:376299][854:0x7f9600196a00], txn-recover: Recovering log 4 through 5
2019-07-26T01:03:55.452+0900 I STORAGE [initandlisten] WiredTiger message [1564070635:452166][854:0x7f9600196a00], txn-recover: Recovering log 5 through 5
2019-07-26T01:03:55.553+0900 I STORAGE [initandlisten] WiredTiger message [1564070635:553501][854:0x7f9600196a00], txn-recover: Set global recovery timestamp: 0
2019-07-26T01:03:55.743+0900 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten]
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten]
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten]
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten]
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2019-07-26T01:03:56.093+0900 I CONTROL [initandlisten]
2019-07-26T01:03:56.437+0900 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongodb/diagnostic.data'
2019-07-26T01:03:56.440+0900 I NETWORK [initandlisten] waiting for connections on port 27017
2019-07-26T01:03:57.017+0900 I FTDC [ftdc] Unclean full-time diagnostic data capture shutdown detected, found interim file, some metrics may have been lost. OK
root#ubuntu:/data/db# ls -al
합계 332
drwxr-xr-x 4 root root 4096 7월 26 00:57 .
drwxr-xr-x 3 root root 4096 7월 20 2018 ..
-rw------- 1 root root 46 7월 26 00:45 WiredTiger
-rw------- 1 root root 21 7월 26 00:45 WiredTiger.lock
-rw------- 1 root root 1044 7월 26 00:57 WiredTiger.turtle
-rw------- 1 root root 61440 7월 26 00:57 WiredTiger.wt
-rw------- 1 root root 4096 7월 26 00:55 WiredTigerLAS.wt
-rw------- 1 root root 32768 7월 26 00:55 _mdb_catalog.wt
-rw------- 1 root root 16384 7월 26 00:55 collection-0-6981595682191946835.wt
-rw------- 1 root root 36864 7월 26 00:56 collection-2-6981595682191946835.wt
-rw------- 1 root root 4096 7월 26 00:55 collection-4-6981595682191946835.wt
-rw------- 1 root root 32768 7월 26 00:55 collection-7-6981595682191946835.wt
drwx------ 2 root root 4096 7월 26 01:00 diagnostic.data
-rw------- 1 root root 16384 7월 26 00:55 index-0--23645261368052429.wt
-rw------- 1 root root 4096 7월 26 00:55 index-1--23645261368052429.wt
-rw------- 1 root root 4096 7월 26 00:56 index-2--23645261368052429.wt
-rw------- 1 root root 16384 7월 26 00:55 index-3--23645261368052429.wt
-rw------- 1 root root 32768 7월 26 00:56 index-4--23645261368052429.wt
drwx------ 2 root root 4096 7월 26 00:55 journal
-rw------- 1 root root 6 7월 26 00:55 mongod.lock
-rw------- 1 root root 36864 7월 26 00:57 sizeStorer.wt
-rw------- 1 root root 114 7월 26 00:45 storage.bson
root#ubuntu:/var/lib/mongodb# ls -al
합계 2468
drwxr-xr-x 4 mongodb mongodb 4096 7월 26 01:05 .
drwxr-xr-x 48 root root 4096 7월 21 20:50 ..
-rw------- 1 mongodb mongodb 46 7월 18 2018 WiredTiger
-rw------- 1 mongodb mongodb 21 7월 18 2018 WiredTiger.lock
-rw------- 1 mongodb mongodb 1056 7월 26 01:05 WiredTiger.turtle
-rw------- 1 mongodb mongodb 192512 7월 26 01:05 WiredTiger.wt
-rw------- 1 mongodb mongodb 4096 7월 26 01:03 WiredTigerLAS.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 _mdb_catalog.wt
-rw------- 1 mongodb mongodb 16384 7월 26 01:03 collection-0--6413199990932768598.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-10-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-12-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-14-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-16-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-18-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:04 collection-2--6413199990932768598.wt
-rw------- 1 mongodb mongodb 16384 7월 26 01:03 collection-20-6605498715908891783.wt
-rw------- 1 mongodb mongodb 45056 7월 26 01:03 collection-22-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-24-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-26-6605498715908891783.wt
-rw------- 1 mongodb mongodb 196608 7월 26 01:03 collection-28-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-30-6605498715908891783.wt
-rw------- 1 mongodb mongodb 61440 7월 26 01:03 collection-32-6605498715908891783.wt
-rw------- 1 mongodb mongodb 24576 7월 26 01:03 collection-34-6605498715908891783.wt
-rw------- 1 mongodb mongodb 32768 7월 26 01:03 collection-36-6605498715908891783.wt
-rw------- 1 mongodb mongodb 151552 7월 26 01:03 collection-38-6605498715908891783.wt
-rw------- 1 mongodb mongodb 20480 7월 26 01:03 collection-4--6413199990932768598.wt
-rw------- 1 mongodb mongodb 114688 7월 26 01:03 collection-40-6605498715908891783.wt
-rw------- 1 mongodb mongodb 45056 7월 26 01:03 collection-42-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-44-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-46-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:03 collection-6-6605498715908891783.wt
-rw------- 1 mongodb mongodb 147456 7월 26 01:03 collection-8-6605498715908891783.wt
drwx------ 2 mongodb mongodb 4096 7월 26 01:27 diagnostic.data
-rw------- 1 mongodb mongodb 16384 7월 26 01:03 index-1--6413199990932768598.wt
-rw------- 1 mongodb mongodb 36864 1월 8 2019 index-11-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 1월 31 00:32 index-13-6605498715908891783.wt
-rw------- 1 mongodb mongodb 16384 12월 16 2018 index-15-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 12월 16 2018 index-17-6605498715908891783.wt
-rw------- 1 mongodb mongodb 32768 12월 19 2018 index-19-6605498715908891783.wt
-rw------- 1 mongodb mongodb 16384 12월 19 2018 index-21-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 25 00:05 index-23-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 10 16:36 index-25-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 2월 26 10:29 index-27-6605498715908891783.wt
-rw------- 1 mongodb mongodb 69632 7월 25 10:00 index-29-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 26 01:04 index-3--6413199990932768598.wt
-rw------- 1 mongodb mongodb 36864 2월 26 11:20 index-31-6605498715908891783.wt
-rw------- 1 mongodb mongodb 32768 2월 18 11:25 index-33-6605498715908891783.wt
-rw------- 1 mongodb mongodb 24576 4월 9 21:59 index-35-6605498715908891783.wt
-rw------- 1 mongodb mongodb 32768 2월 21 17:50 index-37-6605498715908891783.wt
-rw------- 1 mongodb mongodb 53248 7월 21 09:00 index-39-6605498715908891783.wt
-rw------- 1 mongodb mongodb 53248 6월 10 22:36 index-41-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 7월 25 00:00 index-43-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 5월 13 10:02 index-45-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 4월 9 16:10 index-47-6605498715908891783.wt
-rw------- 1 mongodb mongodb 20480 8월 9 2018 index-5--6413199990932768598.wt
-rw------- 1 mongodb mongodb 20480 7월 26 01:04 index-6--6413199990932768598.wt
-rw------- 1 mongodb mongodb 36864 2월 26 13:46 index-7-6605498715908891783.wt
-rw------- 1 mongodb mongodb 36864 10월 25 2018 index-9-6605498715908891783.wt
drwx------ 2 mongodb mongodb 4096 7월 26 01:04 journal
-rw------- 1 mongodb mongodb 4 7월 26 01:03 mongod.lock
-rw------- 1 mongodb mongodb 36864 7월 26 01:05 sizeStorer.wt
-rw------- 1 mongodb mongodb 114 7월 18 2018 storage.bson
When I start mongodb I just typed mongod then I cannot find database.
But when I start mongodb like service mongod start I can see database.
I don't know why and what's diffrent between two, but second way I can see db.

MongoDB suddenly won't start

I have been running MongoDB on a RPI for several weeks, and suddenly it won't start. I know there's a lot of similar questions where correcting the permissions seemed to work. However, this has not worked for me.
I suspect a power off of the RPI has caused this problem, but I have no idea how to solve it.
I get the following terminal output:
$ sudo service mongodb start
[FAIL] Starting database: mongodb failed!
More details are shown with the 'mongod' command:
$ mongod
db level locking enabled: 1
mongod --help for help and startup options
Fri Aug 28 14:04:06
Fri Aug 28 14:04:06 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
Fri Aug 28 14:04:06
Fri Aug 28 14:04:06 [initandlisten] MongoDB starting : pid=4036 port=27017 dbpath=/data/db/ 32-bit host=raspberrypi
Fri Aug 28 14:04:06 [initandlisten]
Fri Aug 28 14:04:06 [initandlisten] ** NOTE: This is a development version (2.1.1) of MongoDB.
Fri Aug 28 14:04:06 [initandlisten] ** Not recommended for production.
Fri Aug 28 14:04:06 [initandlisten]
Fri Aug 28 14:04:06 [initandlisten] ** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
Fri Aug 28 14:04:06 [initandlisten] ** see http://blog.mongodb.org/post/137788967/32-bit-limitations
Fri Aug 28 14:04:06 [initandlisten] ** with --journal, the limit is lower
Fri Aug 28 14:04:06 [initandlisten]
Fri Aug 28 14:04:06 [initandlisten] db version v2.1.1, pdfile version 4.5
Fri Aug 28 14:04:06 [initandlisten] git version: f457ff42ec37f2562d1a5ff06b4d96a861414c94
Fri Aug 28 14:04:06 [initandlisten] build info: Linux piplusraspbian 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 armv6l BOOST_LIB_VERSION=1_49
Fri Aug 28 14:04:06 [initandlisten] options: {}
Fri Aug 28 14:04:06 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
Fri Aug 28 14:04:06 dbexit:
Fri Aug 28 14:04:06 [initandlisten] shutdown: going to close listening sockets...
Fri Aug 28 14:04:06 [initandlisten] shutdown: going to flush diaglog...
Fri Aug 28 14:04:06 [initandlisten] shutdown: going to close sockets...
Fri Aug 28 14:04:06 [initandlisten] shutdown: waiting for fs preallocator...
Fri Aug 28 14:04:06 [initandlisten] shutdown: closing all files...
Fri Aug 28 14:04:06 [initandlisten] closeAllFiles() finished
Fri Aug 28 14:04:06 [initandlisten] shutdown: removing fs lock...
Fri Aug 28 14:04:06 [initandlisten] couldn't remove fs lock errno:9 Bad file descriptor
Fri Aug 28 14:04:06 dbexit: really exiting now
The /data/db does exist and seem to have the right permission:
$ ls -l /data
total 8
drwxr-xr-x 2 mongodb mongodb 4096 Aug 28 14:37 db
drwxr-xr-x 4 mongodb mongodb 4096 Aug 28 09:44 db_backup
The content of db has been copied to db_backup to check if that did any change, but it didn't. The db content permissions also seem fine:
$ ls -l /data/db_backup
total 131100
drwxr-xr-x 2 mongodb mongodb 4096 Aug 28 09:44 client-db
-rw------- 1 mongodb mongodb 16777216 Aug 28 09:44 client-db.0
-rw------- 1 mongodb mongodb 33554432 Aug 28 09:44 client-db.1
-rw------- 1 mongodb mongodb 16777216 Aug 28 09:44 client-db.ns
-rwxr-xr-x 1 mongodb mongodb 0 Aug 28 13:52 mongod.lock
drwxr-xr-x 2 mongodb mongodb 4096 Aug 28 09:44 myproject
-rw------- 1 mongodb mongodb 16777216 Aug 28 09:44 myproject.0
-rw------- 1 mongodb mongodb 33554432 Aug 28 09:44 myproject.1
-rw------- 1 mongodb mongodb 16777216 Aug 28 09:44 myproject.ns
I have also tried mongod --repair, but it does not help.
Does anyone have any ideas?
I don't care about the data, as it is all just temporary testing data.
There is a mongod.lock file inside the mongo's data directory, normally is /var/lib/mongodb. The content of this file is the pid of the mongod process.
If the mongod is stopped, the content of this file should be empty. Otherwise the mongod was stopped unexpectedly. To fix and start a new mongod process, assuming that mongo's data directory is /var/lib/mongodb. Just clear the file...
$ echo "" > /var/lib/mongodb/mongod.lock
and start a new mongod process.
$ mongod

Unable to start MongoDB 3.0.2 service on CentOS 7

We are setting up a MongoDB server for the production environment on Amazon EC2 instance, but could not able to start the service. I've followed this documentation for setup. Here are the steps, I've taken for setting up the server:
Added following to /etc/yum.repos.d/mongodb-org-3.0.repo
[mongodb-org-3.0]
name=MongoDB Repository
baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/
gpgcheck=0
enabled=1
And installed MongoDB 3.0.2 using sudo yum install -y mongodb-org-3.0.2
Created three partitions for data, journal & log:
sudo mkdir /mongo
sudo mkdir /mongo/data
sudo mkdir /mongo/log
sudo mkdir /mongo/journal
Created file system for three separate partitions:
sudo mkfs.ext4 /dev/xvdb
sudo mkfs.ext4 /dev/xvdc
sudo mkfs.ext4 /dev/xvdd
Created entry in fstab for reboot:
echo '/dev/xvdb /mongo/data ext4 defaults,auto,noatime,noexec 0 0
/dev/xvdc /mongo/journal ext4 defaults,auto,noatime,noexec 0 0
/dev/xvdd /mongo/log ext4 defaults,auto,noatime,noexec 0 0' | sudo tee -a /etc/fstab
And mounted the partitions:
sudo mount /mongo/data
sudo mount /mongo/journal
sudo mount /mongo/log
Given the permissions and created link
sudo chown mongod:mongod /mongo/data /mongo/journal /mongo/log
sudo ln -s /mongo/journal /mongo/data/journal
Configured ulimit & read ahead settings as given in the documentation link above. Verified permissions and partitions:
[deployer#prod-mongo ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 8.0G 1.3G 6.8G 16% /
devtmpfs 3.6G 0 3.6G 0% /dev
tmpfs 3.5G 0 3.5G 0% /dev/shm
tmpfs 3.5G 57M 3.4G 2% /run
tmpfs 3.5G 0 3.5G 0% /sys/fs/cgroup
/dev/xvdc 7.8G 36M 7.3G 1% /mongo/journal
/dev/xvdb 150G 51M 149G 1% /mongo/data
/dev/xvdd 3.9G 16M 3.6G 1% /mongo/log
Permissions:
[deployer#prod-mongo ~]$ ll /
total 32
lrwxrwxrwx. 1 root root 7 Sep 29 2014 bin -> usr/bin
dr-xr-xr-x. 4 root root 4096 Sep 29 2014 boot
drwxr-xr-x. 17 root root 2860 May 11 12:11 dev
lrwxrwxrwx. 1 root root 7 Sep 29 2014 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Sep 29 2014 lib64 -> usr/lib64
drwxr-xr-x. 2 root root 6 Jun 10 2014 mnt
drwxr-xr-x. 5 mongod mongod 41 May 11 05:06 mongo
drwxr-xr-x. 21 root root 660 May 11 12:47 run
lrwxrwxrwx. 1 root root 8 Sep 29 2014 sbin -> usr/sbin
Inside /mongo
[deployer#prod-mongo ~]$ ll /mongo/
total 12
drwxr-xr-x. 3 mongod mongod 4096 May 11 07:33 data
drwxr-xr-x. 3 mongod mongod 4096 May 11 07:31 journal
drwxr-xr-x. 3 mongod mongod 4096 May 11 08:58 log
After changing the configurations inside /etc/mongodb.conf
logpath=/mongo/log/mongod.log
dbpath=/mongo/data
and when I'm doing: sudo service mongod start, I'm getting this error:
Starting mongod (via systemctl): Job for mongod.service failed. See 'systemctl status mongod.service' and 'journalctl -xn' for details.
[FAILED]
Further logging:
[deployer#prod-mongo ~]$ sudo systemctl status mongod.service
mongod.service - SYSV: Mongo is a scalable, document-oriented database.
Loaded: loaded (/etc/rc.d/init.d/mongod)
Active: failed (Result: exit-code) since Tue 2015-05-12 04:42:10 UTC; 42s ago
Process: 22881 ExecStart=/etc/rc.d/init.d/mongod start (code=exited, status=1/FAILURE)
May 11 04:42:10 ip-xx-xx-xx-xx.local runuser[22887]: pam_unix(runuser:session): session opened for user mongod by (uid=0)
May 11 04:42:10 ip-xx-xx-xx-xx.localdomain runuser[22887]: pam_unix(runuser:session): session closed for user mongod
May 11 04:42:10 ip-xx-xx-xx-xx.local mongod[22881]: Starting mongod: [FAILED]
May 11 04:42:10 ip-xx-xx-xx-xx.local systemd[1]: mongod.service: control process exited, code=exited status=1
May 11 04:42:10 ip-xx-xx-xx-xx.local systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database..
May 11 04:42:10 ip-xx-xx-xx-xx.local systemd[1]: Unit mongod.service entered failed state.
I've followed various articles and blog posts and StackExchange answers but didn't get any solution. Am I missing something?
Update: If I'm directly running the mongodb service from the normal user something like this: sudo mongod --logpath ~/mongod.log --dbpath ~/mongodata, then this service is starting properly.
We tried changing the path of the pid file to another directory, that didn't help either.
I'm guessing you're running a flavour of Linux that uses SELinux (RHEL or CentOS 7, perhaps?)
If so, the issue is that you don't have a permissive policy on your /mongo/ directory that permits access to daemons (like the mongod service.)
From Wikipedia:
SELinux can potentially control which activities a system allows each
user, process and daemon, with very precise specifications. However,
it is mostly used to confine daemons[citation needed] like database
engines or web servers that have more clearly defined data access and
activity rights. This limits potential harm from a confined daemon
that becomes compromised. Ordinary user-processes often run in the
unconfined domain, not restricted by SELinux but still restricted by
the classic Linux access rights
To check whether this is the issue, try this at the shell:
sudo setenforce 0
This should disable SELinux policies and allow the service to run.
For a more permanent solution, see https://wiki.centos.org/HowTos/SELinux
I ran into this problem and actually found a solution for me.
In short, mongodb 3.2 uses the user 'mongod' while older versions use 'mongodb'. Some of the files and directories were owned by 'mongodb' (the older user). Once I chmod'd them to the 'mongod' user, I was able to use systemctl to control the mongod process.
More specifically, it was the "/var/log/mongodb/*" files that had the wrong user ownership.
root#<HOST>:# ls -alh /var/log/mongodb
total 664K
drwxr-xr-x 2 mongod mongod 4.0K Oct 27 12:08 .
drwxr-xr-x. 22 root root 4.0K Oct 27 11:51 ..
-rw-r--r-- 1 mongodb mongodb 3.8K Oct 27 11:48 mongod.log
-rw-r--r-- 1 mongodb mongodb 19K Apr 14 2016 mongod.log.2016-04-14T18-29-34
-rw-r--r-- 1 mongodb mongodb 2.8K Apr 14 2016 mongod.log.2016-04-14T18-30-13
-rw-r--r-- 1 mongodb mongodb 12K Apr 14 2016 mongod.log.2016-04-14T22-27-27
-rw-r--r-- 1 mongodb mongodb 11K Apr 14 2016 mongod.log.2016-04-14T22-29-12
-rw-r--r-- 1 mongodb mongodb 5.6K Apr 18 2016 mongod.log-20160418.gz
-rw-r--r-- 1 mongodb mongodb 0 Apr 18 2016 mongod.log.2016-09-09T17-33-48
-rw-r--r-- 1 mongodb mongodb 3.6K Sep 9 11:34 mongod.log.2016-09-09T17-34-52
-rw-r--r-- 1 mongodb mongodb 23K Sep 9 11:49 mongod.log.2016-09-09T17-49-49
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 11:55 mongod.log.2016-09-09T17-55-15
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 12:02 mongod.log.2016-09-09T18-02-26
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 12:13 mongod.log.2016-09-09T18-13-17
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 12:25 mongod.log.2016-09-09T18-25-01
-rw-r--r-- 1 mongodb mongodb 5.2K Sep 9 12:47 mongod.log.2016-09-09T18-47-54
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 12:52 mongod.log.2016-09-09T18-52-16
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 12:54 mongod.log.2016-09-09T18-54-49
-rw-r--r-- 1 mongodb mongodb 5.0K Sep 9 13:01 mongod.log.2016-09-09T19-01-22
-rw-r--r-- 1 mongodb mongodb 3.0K Sep 9 13:03 mongod.log.2016-09-09T19-03-21
-rw-r--r-- 1 mongodb mongodb 215K Sep 9 14:25 mongod.log.2016-09-09T20-25-59
-rw-r--r-- 1 mongodb mongodb 281K Sep 10 03:42 mongod.log-20160910
-rw-r--r-- 1 mongodb mongodb 0 Sep 10 03:42 mongod.log.2016-10-27T17-42-42
-rw-r----- 1 mongod mongod 0 Sep 29 22:03 mongod.log.rpmnew
Notice the owner of the directory is 'mongod' (the new user) while the log files are all owned by 'mongodb' (the old user).
In case, anyone encountered the same issue with MongoDB startup, here is the thread of comments https://jira.mongodb.org/browse/SERVER-18439. This is scheduled to be fixed in 3.1.

Mongodb - cannot set dbpath to point to another volume

/etc/mongodb.conf:
# Where to store the data.
dbpath=/vol3/var/lib/mongodb
$ mongo
MongoDB shell version: 2.4.9
connecting to: test
Thu Jun 26 15:01:24.017 Error: couldn't connect to server 127.0.0.1:27017 at src/mongo/shell/mongo.js:145
exception: connect failed
$ less +G /var/log/mongodb/mongodb.log
Thu Jun 26 14:16:26.462 [initandlisten] exception in initAndListen: 10296
*********************************************************************
ERROR: dbpath (/vol3/var/lib/mongodb) does not exist.
Create this directory or give existing directory in --dbpath.
See http://dochub.mongodb.org/core/startingandstoppingmongo
*********************************************************************
, terminating
Thu Jun 26 14:16:26.462 dbexit:
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: going to close listening sockets...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: going to flush diaglog...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: going to close sockets...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: waiting for fs preallocator...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: lock for final commit...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: final commit...
Thu Jun 26 14:16:26.462 [initandlisten] shutdown: closing all files...
Thu Jun 26 14:16:26.462 [initandlisten] closeAllFiles() finished
Thu Jun 26 14:16:26.462 dbexit: really exiting now
$ ls -lah /vol3/var/lib/mongodb
ubuntu#ip-172-31-41-33:~$ ls -lah /vol3/var/lib/mongodb
total 45G
drwxr-xr-x 4 mongodb mongodb 4.0K Jun 26 14:14 .
drwxr-xr-x 42 root root 4.0K Apr 24 06:50 ..
drwxr-xr-x 2 mongodb mongodb 4.0K May 21 08:56 journal
-rw------- 1 mongodb mongodb 64M May 20 09:34 test.0
-rw------- 1 mongodb mongodb 128M May 20 09:34 test.1
-rw------- 1 mongodb mongodb 16M May 20 09:34 test.ns
drwxr-xr-x 2 mongodb mongodb 4.0K May 13 23:33 vita
-rw------- 1 mongodb mongodb 64M May 20 09:37 vita.0
-rw------- 1 mongodb mongodb 128M May 17 11:51 vita.1
-rw------- 1 mongodb mongodb 2.0G May 20 09:39 vita.10
-rw------- 1 mongodb mongodb 2.0G May 20 09:39 vita.11
-rw------- 1 mongodb mongodb 2.0G May 17 18:58 vita.12
-rw------- 1 mongodb mongodb 2.0G May 17 19:05 vita.13
-rw------- 1 mongodb mongodb 2.0G May 15 23:47 vita.14
-rw------- 1 mongodb mongodb 2.0G May 15 15:09 vita.15
-rw------- 1 mongodb mongodb 2.0G May 17 11:50 vita.16
-rw------- 1 mongodb mongodb 2.0G May 16 12:36 vita.17
-rw------- 1 mongodb mongodb 2.0G May 16 13:20 vita.18
-rw------- 1 mongodb mongodb 2.0G May 16 13:59 vita.19
-rw------- 1 mongodb mongodb 256M May 17 11:51 vita.2
-rw------- 1 mongodb mongodb 2.0G May 16 14:39 vita.20
-rw------- 1 mongodb mongodb 2.0G May 16 15:20 vita.21
-rw------- 1 mongodb mongodb 2.0G May 16 16:02 vita.22
-rw------- 1 mongodb mongodb 2.0G May 17 16:31 vita.23
-rw------- 1 mongodb mongodb 2.0G May 17 19:00 vita.24
-rw------- 1 mongodb mongodb 2.0G May 18 08:23 vita.25
-rw------- 1 mongodb mongodb 512M May 17 11:51 vita.3
-rw------- 1 mongodb mongodb 1.0G May 17 11:51 vita.4
-rw------- 1 mongodb mongodb 2.0G May 17 11:51 vita.5
-rw------- 1 mongodb mongodb 2.0G May 17 21:42 vita.6
-rw------- 1 mongodb mongodb 2.0G May 17 18:56 vita.7
-rw------- 1 mongodb mongodb 2.0G May 17 19:04 vita.8
-rw------- 1 mongodb mongodb 2.0G May 17 17:25 vita.9
-rw------- 1 mongodb mongodb 16M May 20 09:39 vita.ns
/vol3 was created was monted from /dev/xvdf, and as you can see the files are there.
Any clue on what's wrong will be greatly appreciated.

How can I manage the disk size of a GridFS MongoDB database?

I have a GridFS MongoDB database that I need to manage the size of. It has been running very well since it was created, but I have never really looked at its disk size until now.
Judging by this outout from the db.stats() command
> db.stats()
{
"db" : "documents",
"collections" : 4,
"objects" : 10967,
"avgObjSize" : 52491.573994711405,
"dataSize" : 575675092,
"storageSize" : 595255296,
"numExtents" : 24,
"indexes" : 4,
"indexSize" : 686784,
"fileSize" : 2080374784,
"nsSizeMB" : 16,
"ok" : 1
}
it seems the database itself is roughly 600MB. This size makes sense to me as it is the same size as the database backups I get from mongodump. The file size is far larger though, and it gets worse when I look in the data directory itself in /var/lib/mongodb:
root#deathstar:/var/lib/mongodb# ls -la
total 2474036
drwxr-xr-x 5 mongodb mongodb 4096 Apr 15 09:28 .
drwxr-xr-x 62 root root 4096 Mar 4 07:48 ..
drwxr-xr-x 2 mongodb mongodb 4096 Apr 13 11:48 documents
-rw------- 1 mongodb mongodb 67108864 Apr 15 09:16 documents.0
-rw------- 1 mongodb mongodb 134217728 Apr 13 11:48 documents.1
-rw------- 1 mongodb mongodb 268435456 Apr 13 11:48 documents.2
-rw------- 1 mongodb mongodb 536870912 Apr 15 09:16 documents.3
-rw------- 1 mongodb mongodb 1073741824 Apr 13 11:50 documents.4
-rw------- 1 mongodb mongodb 16777216 Apr 15 09:16 documents.ns
drwxr-xr-x 2 mongodb mongodb 4096 Apr 13 11:50 journal
-rwxr-xr-x 1 mongodb mongodb 5 Apr 13 11:46 mongod.lock
drwxr-xr-x 2 mongodb mongodb 4096 Apr 15 09:28 _tmp
-rw------- 1 mongodb mongodb 67108864 Apr 15 09:28 -v.0
-rw------- 1 mongodb mongodb 67108864 Apr 15 09:28 v.0
-rw------- 1 mongodb mongodb 134217728 Apr 15 09:28 -v.1
-rw------- 1 mongodb mongodb 134217728 Apr 15 09:28 v.1
-rw------- 1 mongodb mongodb 16777216 Apr 15 09:28 -v.ns
-rw------- 1 mongodb mongodb 16777216 Apr 15 09:28 v.ns
And this in /var/lib/mongodb/journal:
root#deathstar:/var/lib/mongodb/journal# ls -la
total 3145752
drwxr-xr-x 2 mongodb mongodb 4096 Apr 13 11:50 .
drwxr-xr-x 5 mongodb mongodb 4096 Apr 15 09:28 ..
-rw------- 1 mongodb mongodb 1073741824 Apr 15 09:28 j._2
-rw------- 1 mongodb mongodb 88 Apr 15 09:28 lsn
-rw------- 1 mongodb mongodb 1073741824 May 5 2012 prealloc.1
-rw------- 1 mongodb mongodb 1073741824 May 5 2012 prealloc.2
Now correct me if I'm wrong, but I am basically looking at 5.5GB disk size for a 600MB database. That is pretty inefficient.
How can I reduce the disk size? Is there a similar command to OPTIMIZE TABLE in MySQL?
I don't know whether GridFS is a different beast from a regular database, but I tried running compact but it didn't do anything to the disk size.
And how about the journal files? Can I somehow reduce the disk size of all journal files?
The issue with large files is not specific to GridFS.
Journal is there to provide durability, and MongoDB always preallocates files before it needs them. I would recommend not changing anything here - i.e. continue using journaling to protect your files in case of an unexpected crash of the server.
You see much smaller files with mongodump because you don't get the preallocated data files nor journal files.
If you want to have smaller DB directory, I recommend looking at --smallfiles and --noprealloc options to mongod. Both affect one when space is allocated and how much is allocated at a time.