MongoDB ne démarre pas après avoir changé le répertoire de données

J'ai installé une mongodbinstance en utilisant yum. . Maintenant, tout fonctionne bien. J'ai commencé le service en utilisant service mongod start. Ça marche bien. Ensuite, j'ai changé le data directoryet log pathdans le fichier de configuration. J'ai redémarré le serveur et j'ai démarré le service. Mais j'obtiens l'erreur ci-dessous:

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

Quand je donne, systemctl status mongod.serviceje reçois ce qui suit:

 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.

Quand je donne, journalctl -xnje reçois ce qui suit:

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

Quelqu'un peut-il m'aider à résoudre ce problème? Merci!!!

PS : Le répertoire de données que j'ai créé a toutes les autorisations pour l'utilisateur. Mais encore une fois, si je change le répertoire de données par défaut ( /var/lib/mongodb), cela fonctionne très bien.

J'ai rencontré un problème similaire et j'ai trouvé que c'était un mongod.conffichier mal configuré dans mon cas. Il se peut également que les autorisations sur le nouveau répertoire ne soient pas définies correctement. chown -R mongod:mongod <directory name>était la façon dont je garantissais l'accès (et bien sûr chmod 600 <dir>aussi). Enfin, exécutez un ls -Zpour vous assurer que le contexte est correct. Je viens de comparer au répertoire par défaut qui fonctionnait pour moi.

Si cela n'est pas déjà résolu, veuillez également afficher le contenu de votre fichier journal. Il peut y avoir des indices là-bas.

S'étendant sur ce que @mustaccio a dit, la réponse pour moi était le contexte SELinux sur le nouveau logpathet le dbpath. J'ai exécuté les commandes suivantes et tout allait bien:

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

(c'était sur RHEL 7.1 btw)

Je l'avais sur Raspberry Pi ainsi que sur mon serveur Ubuntu.

«Le travail pour mongod.service a échoué. Voir «systemctl status mongod.service» et «journalctl -xn» pour plus de détails. »

J'ai eu ce problème à différentes occasions pour différentes raisons:

1. Fichier .conf mal nommé - Le script mongodb (vers lequel je me suis déplacé /etc/init.d/mongodb), ligne 57 CONF=/etc/mongod.conflorsque mon fichier réel était /etc/mongodb.conf. Changer la ligne 57 l'a corrigé. De plus, j'aurais pu changer le nom du script tout de même.

2. Fichier mongod.lock - La dernière fois que mongod s'est arrêté, il n'a pas eu la possibilité de fermer la base de données. Cela laisse un fichier dans votre dossier de base de données appelé mongod.lock. Le dossier contient un nombre (je crois que c'est le PID que mongo utilisait en dernier). Si ce fichier existe, vous ne pourrez pas démarrer le service mongod. Supprimez le fichier et réessayez.

3. utilisateur mongo - Je devais créer un utilisateur linux qui serait responsable du démarrage et de l'exécution de mongod.service. J'ai nommé le mongo et mis à jour mon /etc/init.d/mongodbscript, ligne 95 pour moi, pour dire DAEMONUSER=${DAEMONUSER:-mongo}. Bien sûr, cela ne fonctionnera que si vous avez créé un nouvel utilisateur nommé mongo (ou ce que vous voulez, je pense).

4. Autorisations DB - C'est une autorisation populaire. Une fois que vous avez déclaré l'emplacement du dossier de la base de données, vous devez vous assurer que votre utilisateur «mongo» est propriétaire de ce fichier. Par exemple, ma base de données est stockée dans /data/db. J'ai exécuté la commande suivante:
   sudo chown –R mongo:mongo /data
   et cela a déplacé la propriété de /datatous ses sous-répertoires vers l'utilisateur mongo.

5. Mauvais service - Celui-ci était un peu gênant pour moi. J'essayais de commencer mongocomme service au lieu de mongod. mongoest le shell que vous pouvez exécuter et saisir manuellement des commandes directement sur mongo. C'est ainsi que j'ai créé ma base de données et ajouté quelques objets par exemple. mongodd'autre part, le démon mongo qui s'exécute en arrière-plan hébergeant votre base de données pour d'autres applications que vous écrivez / utilisez pour accéder. Assurez-vous de ne pas les mélanger n'importe où dans vos fichiers de conf, vos scripts, etc.

J'espère que l'un d'eux résoudra le problème pour vous.

En passant, mon mongodb.confdossier est vide. Même s'il est vide, vous devez le pointer correctement.

J'ai essayé ça et ça a marché.

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

J'ai rencontré ce problème lors de la mise à niveau de mongo fourni avec Centos 7 Repos vers le propre référentiel Mongos. Effectivement, mise à niveau de V2 vers V3.

Il s'avère que le repo de centos 7 nécessite l'utilisateur mongodb , tandis que le propre repo de mongos veut que l'utilisateur mongod

En fin de compte, c'est le fichier journal qui existait toujours de l'ancienne installation que la nouvelle installation ne pouvait pas écrire, car les noms d'utilisateur étaient différents et je ne l'avais pas remarqué.

Sur mon système (Fedora), j'ai "/ var / log" sur un tmpfs (ram), si chaque fois que je redémarre, tout sur cette partition est perdu. Beaucoup de gens à cela parce qu'ils ont des disques SSD et veulent réduire les E / S (économiser la durée de vie du disque).

La solution consiste à créer le répertoire / var / log / mongodb et à définir mongodb comme propriétaire à chaque redémarrage du système.

Utilisez un script comme:

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

Si vous n'êtes pas sûr de ce que l'utilisateur utilise par mongod, faites-le:

cat /etc/passwd | grep mongo

Ajoutez le script au démarrage de votre système.

Vous ne modifiez pas le chemin. J'ai résolu le problème par la commande:

mongod --dbpath /data/mongo

Il s'agit d'un problème d'autorisation. lorsque nous changeons le chemin du répertoire de données ou du fichier journal, nous devons donner des autorisations au nouveau répertoire. Ensuite, cela fonctionne bien. Si un problème survient comme celui-ci, vérifiez d'abord le fichier journal "mongod.log".

Arrêtez le serveur MongoDB:

service mongod stop

Copiez le répertoire mongo dans un nouveau répertoire:

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

Renommer l'ancien répertoire:

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

Lien symbolique vers le nouvel emplacement:

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

Démarrez le serveur MongoDB:

service mongod start