J'ai des problèmes pour lancer mongod en tant que service: Comment est-il possible que cela fonctionne lorsque je fais Sudo mongod -f /etc/mongod.conf mais lors du lancement avec le service Sudo mongod start, un message d'erreur s'affiche
Assertion: 28595:13: Permission denied src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267
Je cours mongodb sur Ubuntu 16
J'ai suivi exactement les instructions de la documentation de mongodb pour l'installation de cette version, s'agit-il d'un bogue? Toutes les suggestions pour résoudre ceci sont appréciées.
Information additionnelle:
Le script de démarrage du service mongodb ressemble à ceci et s’exécute en tant qu’utilisateur mongodb, est-ce que cela pourrait être lié à l’erreur? lib/systemd/system/mongodb.service:
[Unit]
Description=MongoDB Database Service
Wants=network.target
After=network.target
[Service]
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
User=mongodb
Group=mongodb
StandardOutput=syslog
StandardError=syslog
[Install]
WantedBy=multi-user.target
J'ai des problèmes pour lancer mongod en tant que service: comment est-il possible que cela fonctionne lorsque je fais Sudo mongod -f /etc/mongod.conf mais lors du lancement avec le service Sudo mongod start, une erreur s'est produite dans le journal
La commande Sudo
démarre mongod
avec les autorisations root
(alias accès superutilisateur ). Si vous exécutez mongod
en tant que service, l'utilisateur et le groupe sont configurés dans la définition de service (mongodb
pour les deux dans votre exemple).
Il n'est pas nécessaire d'exécuter le processus mongod
en tant qu'utilisateur root
et cela est fortement déconseillé, conformément à la pratique de sécurité courante de Principe du moindre privilège .
Si vous souhaitez tester une configuration à partir de la ligne de commande, vous pouvez utiliser Sudo
pour s'exécuter avec un utilisateur spécifié à la place de l'utilisateur par défaut (root).
Par exemple:
Sudo -u mongodb mongod -f /etc/mongod.conf
En général, il est préférable d'utiliser une configuration de service plutôt que d'exécuter mongod
manuellement. Avec l'appel manuel, vous devez également vous rappeler d'inclure des paramètres tels que le chemin du fichier de configuration (car il n'y a pas de chemin de configuration par défaut). Sans fichier de configuration, mongod
utilise également des options par défaut, telles que dbPath
de /data/db
.
Assertion: 28595: 13: autorisation refusée src/mongo/db/stockage/wiredtiger/wiredtiger_kv_engine.cpp 267
La cause probable de vos erreurs d'autorisation est d'avoir précédemment lancé mongod
en tant qu'utilisateur root
. Certains répertoires et fichiers peuvent maintenant appartenir à l'utilisateur root. Par conséquent, l'utilisateur mongodb
ne peut pas y accéder. Votre erreur spécifique est liée à l’accès aux fichiers du répertoire de données (c’est-à-dire le storage.dbPath
configuré dans mongod.conf
).
En supposant que vous n’ayez pas modifié les chemins par défaut dans votre fichier mongod.conf
, vous devriez pouvoir ajuster de manière récursive les autorisations pour correspondre aux attentes de la définition mongod.service
.
Tout d’abord, assurez-vous d’avoir arrêté votre instance mongod
si elle est en cours d’exécution.
Ensuite, ajustez de manière récursive les autorisations sur l'utilisateur et le groupe attendus:
# storage.dbPath
Sudo chown -R mongodb:mongodb /var/lib/mongodb
# systemLog.path
Sudo chown -R mongodb:mongodb /var/log/mongodb
Vous devriez maintenant pouvoir démarrer mongod
en tant que service. Si le service ne parvient pas à démarrer, le fichier journal mongod
devrait contenir davantage de détails (en supposant que le fichier journal puisse être écrit par l'utilisateur du service mongodb
).
J'ai le même problème.
Qu'est-ce qui a été dans /var/log/mongodb/mongod.log:
2017-05-13T13:46:41.152+0700 E STORAGE [initandlisten] WiredTiger error (13) [1494658001:152518][15821:0x7fb843803cc0], connection: /var/lib/mongodb/journal/WiredTigerPreplog.0000000002: file-remove: unlink: Permission denied
2017-05-13T13:46:41.159+0700 I - [initandlisten] Assertion: 28595:13: Permission denied src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267
Nous voyons donc que quelque chose ne peut pas supprimer le fichier "WiredTigerPreplog.0000000002" dans /var/lib/mongodb/journal/So id vient de donner des autorisations, je viens de le faire:
Sudo chmod 764 /var/lib/mongodb/journal/
Si pas aider, essayez:
Sudo chown -R mongodb:mongodb /var/lib/mongodb/ && Sudo chmod 764 /var/lib/mongodb/journal/
Il y a trois configurations qui déclenchent ce genre de problème:
Dans votre cas, vérifiez si /data/db
existe. Si ce n'est pas le cas ou s'il est vide, Mongod essaie le mauvais chemin d'accès. Vous devez le trouver, il se trouve généralement sous /var/lib/mongodb
.
Une fois que vous l'avez trouvé, vous pouvez faire deux choses. Commencez par copier tout le fichier à partir de /data/db
. Deuxièmement, modifiez votre chemin dbpath sous le fichier mongod.conf, qui se trouve (sous linux) à /etc/mongod.conf
. Assurez-vous de démarrer mongod avec le --config
spécifiant le fichier de configuration.
chown mongodb:mongodb dbpath -R
.
Si vous êtes sûr que dbpath est correct et qu'il n'y a aucune instance de WiredTiger.wt là-bas. Votre base de données est cassée. Il n'y a aucun moyen de garantir l'intégrité si vous perdez ce fichier. Réinstallez mongodb en:
Sudo apt-get purge mongodb-org*
Sudo rm -r dbpath
Sudo apt-get install mongodb-org
Éditez: .__ ou copiez dbpath à partir de l’un de vos réplicas.
Je souhaite ajouter un commentaire à la réponse précédente, mais malheureusement, je ne le peux pas encore.
Je suis complètement d'accord avec l'explication de Stennie. C’est exactement ce qui m’est arrivé… .. J'ai toujours exécuté mongod en tant que service, mais aujourd’hui, à cause de certaines modifications apportées, j’ai essayé d’exécuter le processus avec Sudo mongod --auth --dbpath /data/mongodb/
.. pour tester les autorisations et la base de données. changer de lieu. Après cela, le service Mongodod ne fonctionnait plus, à cause de ce problème d'autorisations.
Je dois dire que la commande Sudo chown -R mongodb:mongodb /data/mongodb/
n'a pas immédiatement résolu le problème comme prévu. J'ai dû redémarrer plusieurs fois, supprimer le fichier mongod.lock
sous /data/mongodb/
, relancer à nouveau la commande Sudo chown
.. et enfin tout s'est bien passé.