MongoDB nie uruchamia się po zmianie katalogu danych

10

Zainstalowałem mongodbinstancję używając yum. . Teraz wszystko działa dobrze. Uruchomiłem usługę za pomocą service mongod start. To dobrze działa. Następnie zmieniłem data directoryi log pathw pliku konfiguracyjnym. Zrestartowałem serwer ponownie i uruchomiłem usługę. Ale pojawia się następujący błąd:

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

Kiedy dam systemctl status mongod.service, dostaję poniżej:

 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.

Kiedy dam journalctl -xn, dostaję poniżej:

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

Czy ktoś może mi pomóc to naprawić? Dzięki!!!

PS : Utworzony przeze mnie katalog danych ma wszystkie uprawnienia dla użytkownika. Ale znowu, jeśli zmienię katalog danych na default ( /var/lib/mongodb), działa dobrze.

NOCNIK
źródło

Odpowiedzi:

6

Wystąpił podobny problem i okazało się, że jest to źle skonfigurowany mongod.confplik w moim przypadku. Może to również oznaczać, że uprawnienia do nowego katalogu nie są ustawione poprawnie. chown -R mongod:mongod <directory name>tak zapewniłem dostęp (i oczywiście chmod 600 <dir>również). Na koniec uruchom polecenie, ls -Zaby upewnić się, że kontekst jest poprawny. Właśnie porównałem do domyślnego katalogu, który działał dla mnie.

Jeśli nie zostało to jeszcze rozwiązane, pokaż również zawartość pliku dziennika. Mogą tam być jakieś wskazówki.

Tomek
źródło
4

Rozwijając to, co powiedział @mustaccio, odpowiedzią dla mnie był kontekst SELinux na nowym logpathi dbpath. Uruchomiłem następujące polecenia i wszystko poszło dobrze:

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

(to było na RHEL 7.1 btw)

Ron L.
źródło
4

Miałem to na Raspberry Pi, a także na moim serwerze Ubuntu.

„Praca dla mongod.service nie powiodła się. Aby uzyskać szczegółowe informacje, zobacz „systemctl status mongod.service” i „journalctl -xn”.

Miałem ten problem przy różnych okazjach z różnych powodów:

  1. Błędnie nazwany plik .conf - Skrypt mongodb (do którego przeprowadziłem się /etc/init.d/mongodb), wiersz 57, CONF=/etc/mongod.confgdy mój rzeczywisty plik był /etc/mongodb.conf. Zmiana linii 57 poprawiła to. Mogłem też zmienić nazwę skryptu tak samo.

  2. plik mongod.lock - Ostatni raz mongod nie zatrzymał bazy danych. Pozostawia to plik w folderze bazy danych o nazwie mongod.lock. W folderze znajduje się liczba (uważam, że to PID, którego mongo używał ostatnio). Jeśli ten plik istnieje, nie będzie można uruchomić usługi mongod. Usuń plik i spróbuj ponownie.

  3. użytkownik mongo - musiałem utworzyć użytkownika linux, który byłby odpowiedzialny za uruchomienie i uruchomienie mongod.service. Nazwałem moje mongo i zaktualizowałem swój /etc/init.d/mongodbskrypt, dla mnie wiersz 95 DAEMONUSER=${DAEMONUSER:-mongo}. To oczywiście zadziała tylko wtedy, gdy utworzysz nowego użytkownika o nazwie mongo (lub cokolwiek chcesz, jak sądzę).

  4. Uprawnienia DB - jest to popularne. Po zadeklarowaniu lokalizacji folderu bazy danych należy upewnić się, że użytkownik „mongo” jest właścicielem tego pliku. Na przykład moja baza danych jest przechowywana w /data/db. Uruchomiłem następujące polecenie:
    sudo chown –R mongo:mongo /data
    i to przeniosło własność /datai wszystkie jego podkatalogi na użytkownika mongo.

  5. Niewłaściwa obsługa - ta była dla mnie trochę krępująca. Próbowałem zacząć mongojako usługa zamiast mongod. mongoto powłoka, którą możesz uruchamiać i ręcznie wprowadzać polecenia bezpośrednio do mongo. W ten sposób stworzyłem swoją bazę danych i dodałem na przykład kilka obiektów. mongodz drugiej strony jest demonem mongo, który działa w tle, obsługując bazę danych dla innych aplikacji, do których piszesz / używasz, aby uzyskać dostęp. Upewnij się, że nie pomieszasz ich nigdzie w plikach conf, skryptach itp.

Mam nadzieję, że jedna z nich rozwiąże problem.

Na marginesie mój mongodb.confplik jest pusty. Nawet jeśli jest pusty, musisz poprawnie go wskazać.

Ryan
źródło
2

Próbowałem tego i zadziałało.

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
Mehmet Cakoglu
źródło
1

Wystąpił ten problem podczas aktualizacji z mongo, który jest dostarczany z Centos 7 Repos, do własnych repozytoriów Mongo. W efekcie aktualizacja z V2 do V3.

Okazuje się, że repozytorium centos 7 wymaga użytkownika mongodb , a repo własne mongo chce użytkownika mongodb

Ostatecznie był to plik dziennika, który wciąż istniał ze starej instalacji, do którego nowa instalacja nie mogła zapisać, ponieważ nazwy użytkowników były różne i nie zauważyłem.

baranina
źródło
1

W moim systemie (Fedora) mam "/ var / log" na tmpfs (ram), si za każdym razem, gdy restartuję wszystko na tej partycji gubi się. Wiele osób robi to, ponieważ mają dyski SSD i chcą zmniejszyć liczbę operacji we / wy (oszczędzając żywotność dysku).

Rozwiązaniem jest utworzenie katalogu / var / log / mongodb i ustawienie mongodb jako właściciela przy każdym ponownym uruchomieniu systemu.

Użyj skryptu, takiego jak:

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

Jeśli nie jesteś pewien, z jakiego użytkownika korzysta mongod, po prostu wykonaj:

cat /etc/passwd | grep mongo

Dodaj skrypt do uruchamiania systemu.

Eduardo GR
źródło
0

Nie edytujesz ścieżki. Rozwiązałem problem poleceniem:

mongod --dbpath /data/mongo
davylina
źródło
0

To jest problem z pozwoleniem. kiedy zmieniamy ścieżkę do katalogu danych lub pliku dziennika, musimy dać uprawnienia do nowego katalogu. Potem działa dobrze. Jeśli wystąpił taki problem, najpierw sprawdź plik dziennika „mongod.log”.

naveen dahiya
źródło
To nie pomogło, dałem pełne uprawnienia do folderu „Log” użytkownikowi uruchamiającemu usługę mongod, korzystam z systemu Windows Server 2016. Nadal nie mogę ponownie uruchomić usługi po zmianie ścieżki do pliku dziennika, nadal otrzymuję błąd: „Usługa nie reaguje na funkcję sterowania.”, proszę o jakiś pomysł?
Eddie Kumar,
0

Zatrzymaj serwer MongoDB:

service mongod stop

Skopiuj katalog mongo do nowego katalogu:

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

Zmień nazwę starego katalogu:

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

Symlink do nowej lokalizacji:

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

Uruchom serwer MongoDB:

service mongod start
Mohamed-yassine Belatar
źródło