it-swarm.com.de

MongoDB startet nicht nach dem Ändern des Datenverzeichnisses

Ich habe eine mongodb Instanz mit yum. installiert. Jetzt funktioniert alles gut. Ich habe den Dienst mit service mongod start Gestartet. Es funktioniert gut. Dann habe ich data directory Und log path In der Konfigurationsdatei geändert. Ich habe den Server erneut gestartet und den Dienst gestartet. Aber ich bekomme den folgenden Fehler:

Restarting mongod (via systemctl):  Job for mongod.service failed. See 'systemctl status mongod.service' and 'journalctl -xn' for details.
                                                           [FAILED]

Wenn ich systemctl status mongod.service Gebe, erhalte ich Folgendes:

 Loaded: loaded (/etc/rc.d/init.d/mongod)
   Active: failed (Result: exit-code) since Wed 2015-03-18 11:35:56 IST; 22s ago
  Process: 10672 ExecStop=/etc/rc.d/init.d/mongod stop (code=exited, status=0/SUCCESS)
  Process: 10841 ExecStart=/etc/rc.d/init.d/mongod start (code=exited, status=1/FAILURE)
 Main PID: 10509 (code=exited, status=0/SUCCESS)

Mar 18 11:35:56 localhost systemd[1]: Starting SYSV: Mongo is a scalable, document-oriented database....
Mar 18 11:35:56 localhost runuser[10850]: pam_unix(runuser:session): session opened for user mongod by (uid=0)
Mar 18 11:35:56 localhost runuser[10850]: pam_unix(runuser:session): session closed for user mongod
Mar 18 11:35:56 localhost mongod[10841]: Starting mongod: [FAILED]
Mar 18 11:35:56 localhost systemd[1]: mongod.service: control process exited, code=exited status=1
Mar 18 11:35:56 localhost systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database..
Mar 18 11:35:56 localhost systemd[1]: Unit mongod.service entered failed state.

Wenn ich journalctl -xn Gebe, erhalte ich Folgendes:

-- Logs begin at Wed 2015-03-18 08:56:56 IST, end at Wed 2015-03-18 11:35:56 IST. --
Mar 18 11:30:01 localhost systemd[1]: Starting Session 20 of user root.
-- Subject: Unit session-20.scope has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit session-20.scope has begun starting up.
Mar 18 11:30:01 localhost systemd[1]: Started Session 20 of user root.
-- Subject: Unit session-20.scope has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit session-20.scope has finished starting up.
-- 
-- The start-up result is done.
Mar 18 11:30:01 localhost CROND[10712]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Mar 18 11:35:56 localhost systemd[1]: Starting SYSV: Mongo is a scalable, document-oriented database....
-- Subject: Unit mongod.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit mongod.service has begun starting up.
Mar 18 11:35:56 localhost runuser[10850]: pam_unix(runuser:session): session opened for user mongod by (uid=0)
Mar 18 11:35:56 localhost runuser[10850]: pam_unix(runuser:session): session closed for user mongod
Mar 18 11:35:56 localhost mongod[10841]: Starting mongod: [FAILED]
Mar 18 11:35:56 localhost systemd[1]: mongod.service: control process exited, code=exited status=1
Mar 18 11:35:56 localhost systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database..
-- Subject: Unit mongod.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Kann mir jemand helfen, das zu beheben? Vielen Dank!!!

P.S. : Das von mir erstellte Datenverzeichnis verfügt über alle Berechtigungen für den Benutzer. Aber auch hier funktioniert es einwandfrei, wenn ich das Datenverzeichnis auf Standard (/var/lib/mongodb) Ändere.

10
JERRY

Ich bin auf ein ähnliches Problem gestoßen und habe festgestellt, dass es falsch konfiguriert ist mongod.conf Datei in meinem Fall. Es kann auch sein, dass die Berechtigungen für das neue Verzeichnis nicht richtig festgelegt sind. chown -R mongod:mongod <directory name> war, wie ich den Zugang sicherstellte (und natürlich die chmod 600 <dir> auch). Führen Sie zum Schluss ein ls -Z um sicherzustellen, dass der Kontext korrekt ist. Ich habe gerade mit dem Standardverzeichnis verglichen, das für mich funktioniert hat.

Wenn dies noch nicht behoben ist, zeigen Sie bitte auch den Inhalt Ihrer Protokolldatei an. Möglicherweise gibt es dort einige Hinweise.

6
Tom

Als Antwort auf das, was @mustaccio sagte, war die Antwort für mich der SELinux-Kontext für die neuen logpath und dbpath. Ich habe die folgenden Befehle ausgeführt und alles war gut:

Sudo chcon -Rv --type=mongod_log_t $logpath
Sudo chcon -Rv --type=mongod_var_lib_t $dbpath

(Dies war übrigens auf RHEL 7.1)

4
Ron L

Ich hatte dies sowohl auf Raspberry Pi als auch auf meinem Ubuntu-Server.

„Job für mongod.service fehlgeschlagen. Weitere Informationen finden Sie unter 'systemctl status mongod.service' und 'journalctl -xn'. “

Ich hatte dieses Problem bei verschiedenen Gelegenheiten aus verschiedenen Gründen:

  1. Falsch benannte .conf-Datei - Das Mongodb-Skript (das ich in /etc/init.d/mongodb Verschoben habe), Zeile 57 CONF=/etc/mongod.conf, Als meine eigentliche Datei /etc/mongodb.conf War. Durch Ändern der Zeile 57 wurde dies korrigiert. Außerdem hätte ich den Skriptnamen trotzdem ändern können.

  2. mongod.lock file - Als mongod das letzte Mal gestoppt hat, hatte es keine Chance, die Datenbank zu schließen. Dadurch verbleibt eine Datei in Ihrem Datenbankordner mit dem Namen mongod.lock. In dem Ordner befindet sich eine Nummer (ich glaube, es ist die PID, die Mongo zuletzt verwendet hat). Wenn diese Datei vorhanden ist, können Sie den Mongod-Dienst nicht starten. Löschen Sie die Datei und versuchen Sie es erneut.

  3. mongo user - Ich musste einen Linux-Benutzer erstellen, der für das Starten und Ausführen des mongod.service verantwortlich ist. Ich habe meinen Mongo benannt und mein /etc/init.d/mongodb - Skript, Zeile 95, aktualisiert, um DAEMONUSER=${DAEMONUSER:-mongo} Zu sagen. Dies funktioniert natürlich nur, wenn Sie einen neuen Benutzer namens mongo erstellt haben (oder was auch immer Sie wollen, denke ich).

  4. DB-Berechtigungen - Dies ist eine beliebte. Sobald Sie angegeben haben, wo sich der Datenbankordner befindet, müssen Sie sicherstellen, dass Ihr Mongo-Benutzer Eigentümer dieser Datei ist. Zum Beispiel wird meine Datenbank unter /data/db Gespeichert. Ich habe den folgenden Befehl ausgeführt:
    Sudo chown –R mongo:mongo /data
    und dies verlagerte den Besitz von /data und all seinen Unterverzeichnissen auf den Mongo-Benutzer.

  5. Falscher Service - Dieser war ein bisschen peinlich für mich. Ich habe versucht, mongo als Dienst anstelle von mongod zu starten. mongo ist die Shell, die Sie ausführen und Befehle manuell direkt in Mongo eingeben können. So habe ich meine Datenbank erstellt und zum Beispiel einige Objekte hinzugefügt. mongod ist andererseits der Mongo-Daemon, der im Hintergrund ausgeführt wird und Ihre Datenbank für andere Anwendungen hostet, auf die Sie schreiben/für die Sie zugreifen. Stellen Sie sicher, dass Sie sie nirgendwo in Ihren Conf-Dateien, Skripten usw. verwechseln.

Hoffe, eine davon wird das Problem für Sie beheben.

Nebenbei bemerkt ist meine mongodb.conf - Datei leer. Auch wenn es leer ist, müssen Sie richtig darauf zeigen.

4
Ryan

Ich habe es versucht und es hat funktioniert.

Sudo chown -R mongodb:mongodb /var/log/mongodb
Sudo chown -R mongodb:mongodb /var/lib/mongodb
Sudo chmod -R 755 /var/lib/mongodb
Sudo chmod -R 755 /var/log/mongodb
2
Mehmet Cakoglu

Ich bin auf dieses Problem gestoßen, als ich von Mongo, das mit Centos 7 Repos geliefert wird, auf Mongos eigene Repos umgestiegen bin. Tatsächlich wird ein Upgrade von V2 auf V3 durchgeführt.

Es stellt sich heraus, dass Centos 7 Repo den Benutzer mongodb benötigt, während Mongos eigenes Repo den Benutzer mongod benötigt

Am Ende war es die Protokolldatei, die noch von der alten Installation vorhanden war, in die die neue Installation nicht schreiben konnte, da die Benutzernamen unterschiedlich waren und ich es nicht bemerkt hatte.

1
muttonUp

Auf meinem System (Fedora) habe ich "/ var/log" auf einem tmpfs (ram), si jedes Mal, wenn ich alles auf dieser Partition neu starte, geht alles verloren. Viele Leute tun dies, weil sie SSD-Laufwerke haben und die E/A reduzieren möchten (was die Lebensdauer des Laufwerks spart).

Die Lösung besteht darin, das Verzeichnis/var/log/mongodb zu erstellen und mongodb bei jedem Neustart des Systems als Eigentümer festzulegen.

Verwenden Sie ein Skript wie:

#!/bin/sh
Sudo mkdir /var/log/mongodb
Sudo chown mongodb:mongodb /var/log/mongodb

Wenn Sie nicht sicher sind, welchen Benutzer mongod verwendet, gehen Sie einfach wie folgt vor:

cat /etc/passwd | grep mongo

Fügen Sie das Skript Ihrem Systemstart hinzu.

1
Eduardo G.R.

Stoppen Sie MongoDB Server:

service mongod stop

Kopieren Sie das Mongo-Verzeichnis in ein neues Verzeichnis:

rsync -av /var/lib/mongo /home/data/

Altes Verzeichnis umbenennen:

mv /var/lib/mongo /var/lib/mongo.bak

Symlink zum neuen Standort:

ln -s /home/data/mongo /var/lib/mongo

Starten Sie MongoDB Server:

service mongod start

Dies ist ein Berechtigungsproblem. Wenn wir den Pfad des Datenverzeichnisses oder der Protokolldatei ändern, müssen wir dem neuen Verzeichnis Berechtigungen erteilen. Dann läuft es gut. Wenn ein solches Problem aufgetreten ist, überprüfen Sie zunächst die Protokolldatei "mongod.log".

0
naveen dahiya

Sie bearbeiten den Pfad nicht. Ich habe das Problem mit dem Befehl gelöst:

mongod --dbpath /data/mongo
0
davylin