1

I had tried to start the MongoDB service using the following command in linux machine.

service mongod restart

I am getting the following error

Stopping mongod:                                           [FAILED]
Starting mongod: about to fork child process, waiting until server is ready for connections.
forked process: 1428
all output going to: /data/log/mongod.log
child process started successfully, parent exiting

I am having the config file as follows

dbpath = /data/db/
logpath = /data/log/mongod.log
logappend = true
fork = true
port = 27017
pidfilepath = /var/run/mongod.pid
rest = true
maxConns = 12000
oplogSize = 10000
directoryperdb = true
keyFile = /etc/mongod.key
master = true
smallfiles = true

Note

 service mongod status
 mongod dead but subsys locked

Any suggestion will be helpful.

  • 1
    I'm not familiar with MongoDB myself, but I'm pretty sure you're going to end up needing to post the contents of /data/log/mongod.log before anybody is going to be able to help you troubleshoot. – Avarkx Jan 20 '14 at 13:32
  • 2
    definitely going to need the contents of the logs to make an accurate diagnosis here - the common cases (permissions, disk issues, running as root previously etc.) have been covered several times, so best to check the logs and then see if your issue has already been answered – Adam C Jan 25 '14 at 3:28
0

$ rm -f /var/lock/subsys/mongod

$ rm -f /var/lib/mongodb/mongod.lock

|improve this answer|||||
  • 1
    Giving commands without comments is a dangerous thing to do. Please explain what the above commands do, even if it will be obvious to many readers. – KookieMonster Jan 28 '15 at 8:40
0

As a quick-fix you can remove/release the lock such as following the response provided by @user57473, which is to suggest running:

$ rm -f /var/lock/subsys/mongod

and/or

$ rm -f /var/lib/mongodb/mongod.lock

However, I think a little more background information about all of this can provide more insight so users have a better understanding of what is going on and what the fix is doing (as user @KookieMonster eluded to in his/her comment, and rightfully so)


Ordinarily when you start a system service or use an init-script with Linux (different Linux versions/distros will use SystemV, Upstart, SystemD often to launch and manage services), the process will be started (identified with a Process Identifier - or Pid) and a lock file will be added (usually to default path: /var/lock/subsys/ , and file owned by root with permissions 644); the existence of these files are enough to be perceived as a lock-state, so you could essentially create these by running a command such as sudo touch /var/lock/subsys/foo for example. In this case a lock would be created named "foo" which ordinarily should match to a process with the same name "foo" containing a Pid. The purpose of the lock file is similar to mutexes/semaphores in programming - it can be used to ensure only one instance of a service is launched at any given time, or it can be used to ensure consistency in the event of unexpected states. For example, if a power failure suddenly kills a server, it will terminate the process but will not remove the lock file. If the server is rebooted, the attempt to relaunch a service may look to see that there is no current process/pid but there is currently a lock file for it which can indicate that some recovery processing or cleanup processing must be invoked before the process is allowed to start-up normally.

In the case of MongoDB, you may start mongodb by running sudo service mongod which will create a running process named mongod with a given Pid and also create the lock file with the same name mongod at the path /var/lock/subsys/mongod. Ordinarily, when you shutdown a service gracefully/properly you might use a command like sudo service mongod stop which will stop the running process and remove the lock file. However if your mongod service process unexpectedly terminated but left this lock file, it could indicate something like a power failure, or perhaps some errors occurred - which is why you should check through your log files to determine what happened. Starting back up, these lock file(s) could indicate that the process needs to ensure data consistency before the process is able to start, or before the database is made available.

More info about the subsys lock files can be found here

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.