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
$ 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