Я запускаю MongoDB 2.2 на Ubuntu, и если я запускаю:
sudo mongod
Я получаю сообщение об ошибке, которое не может найти /data/db, а не где находится база данных. В mongod.conf путь к базе данных задается как Ubuntu 10gen по умолчанию /var/lib/mongodb
, где находится db. Кажется, что mongod
не находит файл conf. Поэтому, когда я запускаю:
sudo mongod -f /etc/mongodb.conf
Сервер запускается нормально, и вывод записывается в файл журнала: /var/log/mongodb/mongodb.log
. Все счастливы. Я могу переключиться на другую оболочку, войти в оболочку mongo, посмотреть базы данных и выполнить запросы.
Итак, я отменяю это и пытаюсь запустить службу:
> sudo status mongodb
mongodb stop/waiting
> sudo start mongodb
mongodb start/running, process 10468
Выглядит хорошо, но сервер mongo не запускался. Запуск другой:
> sudo status mongodb
mongodb stop/waiting
> mongo
MongoDB shell version: 2.2.0
connecting to: test
Sat Sep 1 19:07:43 Error: couldn't connect to server 127.0.0.1:27017 src/mongo/shell/mongo.js:91
exception: connect failed
"test" - это не правильная база данных, и ничего не отображается в файле журнала.
Я не понимаю, что может быть неправильным. Я проверил сценарии выскочки, и они кажутся прекрасными. /etc/init/mongodb.conf
работает:
mongodb --exec /usr/bin/mongod -- --config /etc/mongodb.conf
ОК, все это сводится к разрешениям, но пусть это займет шаг за шагом. Когда вы запускаете sudo mongod
, он вообще не загружает файл конфигурации, он буквально начинается с скомпилированных по умолчанию - порт 27017, путь к базе данных/data/db и т.д. - вот почему вы получили сообщение об отсутствии возможности найти эту папку. "Ubuntu default" используется только тогда, когда вы указываете его в файле конфигурации (если вы начинаете использовать служебную команду, это делается для вас за кулисами).
Затем вы запускаете его следующим образом:
sudo mongod -f /etc/mongodb.conf
Если раньше не было проблем, тогда будет - вы запустили процесс, с вашей обычной конфигурацией (указывая на свой обычный dbpath и log) как пользователь root. Это означает, что в этой обычной папке MongoDB теперь будет несколько файлов с группой user: group root:root
.
Это приведет к ошибкам при попытке запустить его как обычный сервис еще раз, потому что пользователь mongodb (который служба будет пытаться выполнить как) не получит разрешения на доступ к этим файлам root:root
, и, самое главное, это вероятно, не сможет записать в файл журнала, чтобы предоставить вам любую информацию.
Поэтому, чтобы запустить его как обычный сервис, нам необходимо исправить эти разрешения. Во-первых, убедитесь, что MongoDB в настоящее время не работает как root, а затем:
cd /var/log/mongodb
sudo chown -R mongodb:mongodb .
cd /var/lib/mongodb
sudo chown -R mongodb:mongodb .
Это должно быть исправлено (при условии, что пользователь: группа mongodb:mongodb
), хотя, вероятно, лучше всего проверить с помощью ls -al
или аналогичного, чтобы быть уверенным. Как только это будет сделано, вы сможете снова запустить службу снова.
Сначала подтвердите, что пользователь/группа mongodb имеет разрешение на запись в каталог данных и журнал:
$sudo chown -R mongodb: mongodb/var/lib/mongodb/.
$sudo chown -R mongodb: mongodb/var/log/mongodb.log
Запустите MongoDB как Daemon (фоновый процесс), используя следующую команду:
$mongod --fork --dbpath/var/lib/mongodb/--smallfiles --logpath /var/log/mongodb.log --logappend
В Завершить работу MongoDB войдите в Mongo CLI, получите доступ к администратору и выполните команду shutdown:
$./mongo
использовать admin
db.shutdownServer()
Ссылка: http://www.mongodb.org/display/DOCS/Starting+and+Stopping+Mongo
mongod --shutdown
также будет mongod --shutdown
завершать работу
У меня тоже была такая же проблема. Поэтому я пошел в cd/var/lib/mongodb/и удалил файл mongod.lock Тогда это сработало для меня.
После проверки всех разрешений в папках данных, журналов и журналов, предложенных @nelsonic, моя проблема была решена путем разрешения блокировки файла в папке /tmp
sudo chown mongod:mongod mongodb-27017.sock
Я запускал его как экземпляр AWS Amazon Linux. Я понял это, выполнив в качестве пользователя mongod, как показано ниже, а затем, исследуя код ошибки. Это может быть полезно для других способов устранения неполадок.
sudo -S -u mongod mongod -f /etc/mongod.conf
Ничего не работало для меня, тогда я обнаружил, что это проблема с разрешениями в каталоге /tmp
:
sudo chmod 1777 /tmp
sudo chown root:root /tmp
mongod
не запустится. Это определенно один из них.
Ни один из вышеперечисленных ответов не работал у меня. Я, наконец, понял это, отлажив init script с помощью
sudo bash -x/etc/init.d/mongodb start
И, увидев, что он пропускает неправильный путь конфигурации к mongod. Я просто изменил строку в /etc/init.d/mongodb с "CONF =/etc/mongodb.conf" на "CONF =/etc/mongod.conf". Версия 2 использует первое, а установка версии 3 добавлена /etc/mongod.conf с новым форматом, но, по-видимому, не обновила init script.
UPDATE: У меня теперь гораздо более сложная проблема, когда работает init script, но только если я запустил его с помощью "sudo bash -x/etc/init.d/mongodb start", а не с помощью "sudo service mongodb start". То же самое для остановки.
Мой mongodb запускался при запуске из командной строки в качестве пользователя mongod, но не как сервис с User = mongod. После часа проверки разрешений, определения сервиса, сокетов... это был SElinux!
В /etc/selinux/config я переключился с принудительного на permissive и перезагрузился. Теперь все в порядке.
Просто попробуйте эту команду:
sudo chown mongodb /tmp/mongodb-27017.sock
В наши дни эта ошибка может возникнуть, если вы обновили mongod, и вы работаете, и старая база данных. Mongod будет использовать движок wiredTiger по умолчанию, и у вас будет база данных mmapv1
отредактируйте настройку двигателя в файле /etc/mongod.conf
# engine: wiredTiger
engine: mmapv1
Осторожно - YAML чувствителен к пробелу
journalctl/systemd не увидит эту проблему. Проверьте журнал mongod в /var/log/mongodb/mongod.log
Я предполагаю, что вы можете преобразовать базу данных с чем-то вроде описанных здесь шагов
https://docs.mongodb.com/manual/tutorial/change-standalone-wiredtiger/
После того, как ни один из вышеперечисленных ответов не сработал у меня, удаление моего лог файла привело к оживлению Монго.