Usługa mongodb nie uruchamia się, gdy istnieją dwa adresy IP

1

w pliku /etc/mongodb.conf Mam to ustawienie bindIp:  „127.0.0.1,192.168.1.51”, 192.168.1.51 to mój prywatny adres IP podany przez mój router. kiedy robię systemctl status mongodb:

mongodb.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/usr/lib/systemd/system/mongodb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2016-09-26 17:51:40 CST; 32s ago
   Process: 1070 ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf (code=exited, status=48)
   Main PID: 1070 (code=exited, status=48)

kiedy sprawdzam /var/log/mongodb/mongod.log to otrzymuję:

2016-09-26T17:55:05.129-0600 I CONTROL  [main] ***** SERVER RESTARTED *****
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] MongoDB starting : pid=2916 port=27017 dbpath=/var/lib/mongodb 64-bit host=goku
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] db version v3.2.9
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] git version: 22ec9e93b40c85fc7cae7d56e7d6a02fd811088c
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2i  22 Sep 2016
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] allocator: tcmalloc
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] modules: none
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] build environment:
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten]     distarch: x86_64
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten]     target_arch: x86_64
2016-09-26T17:55:05.135-0600 I CONTROL  [initandlisten] options: { config: "/etc/mongodb.conf", net: { bindIp: "127.0.0.1,
192.168.1.51", port: 27017 }, processManagement: { pidFilePath: "/var/run/mongodb/mongod.pid" }, security: { authorization
: "enabled" }, storage: { dbPath: "/var/lib/mongodb", engine: "wiredTiger", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log", quiet: true } }
2016-09-26T17:55:05.163-0600 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=6G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),f
ile_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2016-09-26T17:55:05.521-0600 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongodb/diagnostic.data'
2016-09-26T17:55:05.521-0600 I NETWORK  [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2016-09-26T17:55:05.522-0600 I NETWORK  [initandlisten] waiting for connections on port 27017

jednak mogę uruchomić systemctl restart mongodb i wszystko działa

Zmodyfikowałem /usr/lib/systemd/system/mongodb.service i dodałem te dwie linie:

Requires=NetworkManager-dispatcher.service NetworkManager.service
After=syslog.target NetworkManager-dispatcher.service NetworkManager.service

więc pytanie o milion dolarów brzmi: co jeszcze powinienem / mógłbym zrobić, aby działał w czasie rozruchu?

dzięki za pomoc :-)

juanp_1982
źródło

Odpowiedzi:

1

Dzienniki mówią, że proces rozpoczął się pomyślnie (ten ostatni wiersz wskazywał na sukces), ale status usługi mówi, że zakończył się.

Dzienniki są o wiele bardziej prawdopodobne, usługa została pomyślnie uruchomiona, ale identyfikatory procesów ( PID ) nie pasuje. Twój status usługi wygląda PID 1070 i dziennik pokazuje 2916. Podejrzewam, że to twój problem, a moim głównym podejrzanym jako przyczyna byłby ten pidFilePath opcja. Sprawdź, co znajduje się w tym pliku i spróbuj usunąć tę opcję, sprawdź, czy to rozwiązuje problem.

Adam C
źródło
Dzięki za odpowiedź! podczas uruchamiania mojego systemu plik pid nie istnieje, a mongodb jest w stanie nieudanym. Ale wtedy mogę rozpocząć proces systemctl start mongodb bez problemu. Usunąłem również opcję pidfilepath i otrzymuję to samo zachowanie
juanp_1982
Wydaje się, że brakuje Ci logów stanu, które nie powiodły się z twojego pytania - opublikowane przez Ciebie dzienniki nie pokazują nieudanego startu, ale odnoszą sukces. Czy możesz opublikować te z awarią? Och, a twój OS / wersja też byłaby pomocna.
Adam C