MongoDB en cours d'exécution mais ne peut pas se connecter à l'aide d'un shell
CentOS 5.x Linux avec MongoDB 2.0.1 (essayé main et legacy-static)
MongoDB est en cours d'exécution:
root 31664 1.5 1.4 81848 11148 ? Sl 18:40 0:00 ./mongod -f mongo.conf -vvvvv --fork
L'utilisation d'un simple shell pour accéder au serveur échoue:
[root@xxxx bin]# ./mongo
MongoDB Shell version: 2.0.1
connecting to: test
Mon Oct 31 18:41:32 Error: couldn't connect to server 127.0.0.1 Shell/mongo.js:84
exception: connect failed
L'interface Web sur le port 28017 se charge correctement, de même que l'utilisation du shell MongoDB à partir d'un hôte Linux distant. Peut également utiliser la commande telnet sur localhost: 27017, ce qui signifie qu'aucun port n'est bloqué. Il n’existe pas non plus de SELinux sur cette machine. J'ai aussi essayé de spécifier explicitement localhost:2017/db en vain.
$ ./mongo remote-ip:27017
MongoDB Shell version: 2.0.1
connecting to: remote-ip:27017/test
> show dbs
local 0.03125GB
>
Les journaux sont complètement mamans sur le sujet:
.....
Mon Oct 31 18:40:34 [initandlisten] fd limit hard:1024 soft:1024 max conn: 819
Mon Oct 31 18:40:34 [initandlisten] waiting for connections on port 27017
Mon Oct 31 18:40:34 BackgroundJob starting: snapshot
Mon Oct 31 18:40:34 BackgroundJob starting: ClientCursorMonitor
Mon Oct 31 18:40:34 BackgroundJob starting: PeriodicTask::Runner
Mon Oct 31 18:40:34 [websvr] fd limit hard:1024 soft:1024 max conn: 819
Mon Oct 31 18:40:34 [websvr] admin web console waiting for connections on port 28017
Stracer le client Shell mongo ne montre qu'un seul appel problématique:
[pid 31708] connect(4, {sa_family=AF_INET, sin_port=htons(27017), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EBADF (Bad file descriptor)
Le système de fichiers est propre, pas de restrictions ulimit (exécuté en tant que root pour les tests). Je vois dans la strace que le client mongo tente de se connecter via TCP (AF_INET), mais étant donné qu’il est local et que MongoDB crée un socket de fichier, existe-t-il un moyen d’indiquer au client de se connecter via cela? Ou mieux encore, pourquoi le client lancerait-il un EBADF?
EDIT: Mon base Mongo conf:
dbpath=/root/mongodb-linux-i686-2.0.1/data
logpath=/root/mongodb-linux-i686-2.0.1/logs/mongo.log
slowms=15
rest=1
Je pense qu'il y a une configuration par défaut qui manque dans cette version du client mongoDb. Essayez de courir:
mongo 127.0.0.1:27017
C'est étrange, mais j'ai alors constaté que le problème avait disparu :) (donc la simple commande 'mongo' sans aucun paramètre a recommencé à fonctionner pour moi)
[Ubuntu Linux 11.10 x64 / MongoDB 2.0.1]
Vous voudrez peut-être vérifier votre configuration pour voir si le bind_ip est défini
bind_ip: 127.0.0.1
Si c'est le cas, cela n'autorise que les connexions locales. Commentez ceci et redémarrez Mongo, cela peut aider.
J'ai eu un problème similaire, et en fait le même (le processus mongo est en cours d'exécution mais ne peut pas s'y connecter). Ce que j'ai fait est allé dans mon chemin d'accès à la base de données et a supprimé mongod.lock, puis j'ai essayé à nouveau (redémarrage de mongo). Après cela a fonctionné.
J'espère que ça marchera pour toi aussi. réparation mongodb sur ubunt
J'ai eu le même problème. Dans mon cas, MongoDB le serveur ne fonctionnait pas.
Essayez de l'ouvrir dans votre navigateur Web:
http://localhost:28017
Si vous ne le pouvez pas, cela signifie que vous devez démarrer le serveur MongoDB.
Exécutez mongod dans un autre onglet de terminal. Ensuite, dans votre onglet principal, exécutez mongo, qui correspond au shell qui se connecte à votre serveur MongoDB.
Supprimer /var/lib/mongodb/mongod.lock, puis lancez Sudo service mongodb start, puis mongo.
Ouvrez le fichier /etc/mongod.conf et ajoutez l'adresse IP de la machine à partir de laquelle vous vous connectez, à bind_ip
bind_ip = 127.0.0.1, votre adresse IP de machine distante ici
Ex:-
bind_ip = 127.0.0.1,192.168.1.5
Redémarrez le service mongodb:
Sudo service mongod restart
Assurez-vous que le port mongodb est ouvert dans le pare-feu.
Vous pouvez également commenter la ligne si vous n'êtes pas inquiet pour la sécurité.
J'ai eu ce problème aussi. Est-ce que votre journalisation MongoDB? J'ai remarqué les entrées "préallouer" suivantes dans le fichier journal. Une fois que j'ai vu la dernière ligne "en attente de connexions sur le port", j'ai pu me connecter. Notez que ce mode "plus rapide" a pris 12 minutes pour s'initialiser.
William
Tue Apr 17 16:48:01 [initandlisten] MongoDB starting : pid=2248 port=27017 dbpath=E:\MongoData 64-bit Host=ME
Tue Apr 17 16:48:01 [initandlisten] db version v2.0.0-rc0, pdfile version 4.5
Tue Apr 17 16:48:01 [initandlisten] git version: 8d4bf50111352cee5a4f1abf25b63442d6c45dc4
Tue Apr 17 16:48:01 [initandlisten] build info: windows (6, 1, 7601, 2, 'Service Pack 1') BOOST_LIB_VERSION=1_42
Tue Apr 17 16:48:01 [initandlisten] options: { bind_ip: "ip", dbpath: "E:\MongoData", directoryperdb: true, journal: true, logpath: "E:\MongoData\mongo.log", quiet: true, rest: true, service: true }
Tue Apr 17 16:48:01 [initandlisten] journal dir=E:/MongoData/journal
Tue Apr 17 16:48:01 [initandlisten] recover : no journal files present, no recovery needed
Tue Apr 17 16:48:02 [initandlisten] preallocateIsFaster=true 9.68
Tue Apr 17 16:48:04 [initandlisten] preallocateIsFaster=true 8.44
Tue Apr 17 16:48:06 [initandlisten] preallocateIsFaster=true 9.68
Tue Apr 17 16:48:06 [initandlisten] preallocateIsFaster check took 4.921 secs
Tue Apr 17 16:48:06 [initandlisten] preallocating a journal file E:/MongoData/journal/prealloc.0
Tue Apr 17 16:52:37 [initandlisten] preallocating a journal file E:/MongoData/journal/prealloc.1
Tue Apr 17 16:56:54 [initandlisten] preallocating a journal file E:/MongoData/journal/prealloc.2
Tue Apr 17 17:01:42 [initandlisten] waiting for connections on port 27017
Tue Apr 17 17:01:42 [websvr] admin web console waiting for connections on port 28017
Par défaut, mongodb est configuré pour écouter uniquement localhost. Extrait du fichier de configuration par défaut de mongodb:
# Listen to local interface only. Comment out to listen on all interfaces.
bind_ip=127.0.0.1
Il faut commenter le bind_ip pour écouter des entités externes.
Vous ne pourrez pas ajouter de fragments si vous ne commencez pas à écouter sur des interfaces non locales.
HTH,
Abhay Dandekar
Si votre bind_ip est défini sur autre chose que 127.0.0.1, vous devrez ajouter l'adresse IP de manière explicite, même à partir de la machine locale. Utilisez donc simplement la même méthode que celle que vous utilisez sur le boîtier distant du boîtier local. Au moins c'est ce qui me l'a fait.
En réalité, ce n'est pas une erreur ... Ce qui se passe ici, c'est que Mongo s'appuie sur un démon pour exécuter le serveur de base de données local. "Lancez" le serveur Mongo de votre shell, vous devez démarrer le service Mongo d'abord.
Pour Fedora Linux (quelle est la distro que j'utilise), vous devez exécuter ces commandes:
1 Sudo service mongod start
2 mongo
Et voila! le serveur va fonctionner. Maintenant, si vous voulez que le service Mongo démarre au démarrage du système, vous devez exécuter:
Sudo chkconfig --levels 235 mongod on
Et c'est tout! Si vous faites cela, maintenant dans le shell il vous suffit de taper mongo pour démarrer le serveur, mais c'est à peu près tout. Le problème, c’est que vous devez d'abord lancer le SERVICE, puis le SERVEUR :)
P.S. Les commandes que j'ai postées pourraient également fonctionner sur d'autres distributions Linux, pas seulement dans Fedora ... Dans le cas contraire, vous devez peut-être modifier quelques mots en fonction de la distribution que vous utilisez;)
Face au même problème avec l'erreur décrite par Garrett ci-dessus. 1. MongoDB Server avec journalisation activée s'exécute comme indiqué à l'aide de la commande ps 2. Le client Mongo ou le pilote Mongoose ne parvient pas à se connecter à la base de données.
Solution: 1. La suppression du fichier Mongo.lock semble ramener la vie à la normale sur le serveur CentOS. 2. Nous sommes assez nouveaux dans la production de MongoDB et constatons le même problème deux fois par semaine. 3. Nous avons mis en place une planification cron pour nettoyer régulièrement le fichier de verrouillage et informer l'administrateur qu'un incident s'est produit.
Rechercher un correctif pour ce problème ou tout autre moyen plus permanent de le résoudre.
Si la version de votre serveur mongoDB (serveur distant) est supérieure à 4.0.3, vous serez confronté à ce problème. Par conséquent, vous devriez remplacer votre shell client mongo actuel par un autre mongo:
Sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4
echo "deb [ Arch=AMD64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse" | Sudo tee /etc/apt/sources.list.d/mongodb-org-4.0.list
Sudo apt-get update
Sudo apt-get install -y mongodb-org
Ensuite, votre client mongo sera en mesure de connecter votre supprimer mongodb
Sur Ubuntu:
Mer. 27 janv. 10:21:32 Erreur: impossible de se connecter au serveur 127.0.0.1 Shell/mongo.js: 84 exception: échec de la connexion
Solution
cherche si mongodb est en cours d'exécution en suivant la commande:
ps -ef | grep mongo
Si Mongo ne fonctionne pas, vous obtenez:
vimal 1806 1698 0 10:11 pts/0 00:00:00 grep --color=auto mongo
Vous voyez que le démon mongo n'est pas là.
Puis lancez-le via le fichier de configuration (avec root priev):
root@vimal:/data# mongod --config /etc/mongodb.conf &
[1] 2131
root@vimal:/data# all output going to: /var/log/mongodb/mongodb.log
vous pouvez voir les autres détails:
root@vimal:~# more /etc/mongodb.conf
Ouvrez un nouveau terminal pour voir le résultat de mongod --config /etc/mongodb.conf puis tapez mongo. Il devrait être en cours d'exécution ou grep
root@vimal:/data# ps -ef | grep mongo
root 3153 1 2 11:39 ? 00:00:23 mongod --config /etc/mongodb.conf
root 3772 3489 0 11:55 pts/1 00:00:00 grep --color=auto mongo
À PRÉSENT
root@vimal:/data# mongo
MongoDB Shell version: 2.0.4
connecting to: test
vous obtenez le shell mongoDB
Ce n'est pas la fin de l'histoire. Je publierai la méthode de réparation de sorte qu'elle démarre automatiquement à chaque fois, la plupart des arrêts de la machine de développement tous les jours et le VM doit avoir démarré automatiquement mongo au prochain démarrage.
Je ne vois pas encore de réponse acceptée, alors je vais simplement ajouter mes 2 centimes.
J'ai eu exactement le même problème tout à l'heure. Après un moment, j'ai réalisé que j'avais verrouillé localhost dans mes règles iptables. Alors, vérifiez votre pare-feu.
Pas tellement une réponse, mais plutôt une FYI: Je viens juste de toucher ceci et j'ai trouvé cette question à la suite d'une recherche. Voici les détails de mon expérience:
Erreur de shell
markdsievers@ip-xx-xx-xx-xx:~$ mongo
MongoDB Shell version: 2.0.1
connecting to: test
Wed Dec 21 03:36:13 Socket recv() errno:104 Connection reset by peer 127.0.0.1:27017
Wed Dec 21 03:36:13 SocketException: remote: 127.0.0.1:27017 error: 9001 socket exception [1] server [127.0.0.1:27017]
Wed Dec 21 03:36:13 DBClientCursor::init call() failed
Wed Dec 21 03:36:13 Error: Error during mongo startup. :: caused by :: DBClientBase::findN: transport error: 127.0.0.1 query: { whatsmyuri: 1 } Shell/mongo.js:84
exception: connect failed
Les journaux Mongo révèlent
Wed Dec 21 03:35:04 [initandlisten] connection accepted from 127.0.0.1:50273 #6612
Wed Dec 21 03:35:04 [initandlisten] connection refused because too many open connections: 819
Cela indique peut-être que l'autre réponse (JaKi) a connu la même situation, certaines connexions ayant été purgées et l'accès rendu possible à nouveau pour Shell (autres clients).
J'ai trouvé ceci très utile.
Si vous recevez le message suivant
start: Rejected send message, 1 matched rules; type="method_call", sender=":1.84" (uid=1000 pid=3215 comm="start mongodb ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
shriprasad@shriprasad-HP-430-Notebook-PC:/var/lib/mongodb$ mongo
Vous devez essayer de démarrer le service mongodb en tant qu’utilisateur autre que root. Vous devez être utilisateur root. Connectez-vous donc en tant que root, puis exécutez la commande suivante comme suit:
Sudo bash
suivi par
service mongodb start
Après avoir démarré le Mongod
$mongod --dbpath <db name>
obtenir Shell
$mongo --Shell