web-dev-qa-db-fra.com

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

J'ai installé une instance mongodb en utilisant yum. . Maintenant, tout fonctionne bien. J'ai démarré le service en utilisant service mongod start. Ça marche bien. Ensuite, j'ai changé le data directory et log path dans 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.service J'obtiens 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 -xn J'obtiens 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!!!

P.S. : 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) ça fonctionne bien.

mongodbconfiguration
10
JERRY

J'ai rencontré un problème similaire et j'ai trouvé que c'était un _ mongod.conf fichier 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 le chmod 600 <dir> ainsi que). Enfin, exécutez un ls -Z pour 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.

6
Tom

S'étendant sur ce que @mustaccio a dit, la réponse pour moi était le contexte SELinux sur les nouveaux logpath et 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)

4
Ron L

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 (que j'ai déplacé vers /etc/init.d/mongodb), ligne 57 CONF=/etc/mongod.conf lorsque 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 pense 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. mongo user - 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/mongodb script, 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 - Ceci est 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 /data et tous ses sous-répertoires à l'utilisateur mongo.

  5. Mauvais service - Celui-ci était un peu gênant pour moi. J'essayais de démarrer mongo en tant que service au lieu de mongod. mongo est 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. mongod d'autre part est le démon mongo qui s'exécute en arrière-plan hébergeant votre base de données pour les 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.conf le fichier est vide. Même s'il est vide, vous devez le pointer correctement.

4
Ryan

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
2
Mehmet Cakoglu

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 repo de mongos veut que l'utilisateur mongod

À la fin, 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é.

1
muttonUp

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.

1
Eduardo G.R.

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
0
Mohamed-yassine Belatar

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 accorder 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".

0
naveen dahiya

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

mongod --dbpath /data/mongo
0
davylin