Отладка systemd для mongodb 3.2 на человечности 16.04 — сигнал 15 уничтожений

Я установил mongodb-org и mongodb-org-server, следующий инструкциям на mongodb.org (хотя для человечности 14.x)

В этой точке, работающей mongodb непосредственно, работает;

sudo -H -u mongodb bash -c "/usr/bin/mongod -f /etc/mongod.conf"

в /var/log/mongodb.log

2016-06-15T00:57:10.718Z I NETWORK  [initandlisten] waiting for connections on port 27017

Я пристроил/lib/systemd/system/mongodb.service (подобный https://gist.github.com/sgnn7/54146c8a13c8b5ca2201)

[Unit]
Description=High-performance, schema-free document-oriented database
After=syslog.target network.target

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod -f /etc/mongod.conf
ExecStop=/usr/bin/mongod -f /etc/mongod.conf --shutdown

[Install]
WantedBy=multi-user.target

В mongodb.log это - результат;

2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] MongoDB starting : pid=5592 port=27017 dbpath=/data/wiredtiger 64-bit host=neptune
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] db version v3.2.7
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] git version: 4249c1d2b5999ebbf1fdf3bc0e0e3b3ff5c0aaf2
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g-fips  1 Mar 2016
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] allocator: tcmalloc
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] modules: none
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] build environment:
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     distmod: ubuntu1404
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     distarch: x86_64
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     target_arch: x86_64
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", port: 27017, unixDomainSocket: { enabled: true, filePermissions: 329, pathPrefix: "/data/wiredtiger" } }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongodb.pid" }, setParameter: { failIndexKeyTooLong: "false" }, storage: { dbPath: "/data/wiredtiger", directoryPerDB: true, engine: "wiredTiger", journal: { enabled: true }, wiredTiger: { collectionConfig: { blockCompressor: "snappy" }, engineConfig: { cacheSizeGB: 1, directoryForIndexes: true } } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongodb.log", timeStampFormat: "iso8601-utc" } }
2016-06-15T00:47:53.770Z I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.270Z I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/wiredtiger/diagnostic.data'
2016-06-15T00:47:54.271Z I NETWORK  [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2016-06-15T00:47:54.271Z I NETWORK  [initandlisten] waiting for connections on port 27017
2016-06-15T00:47:54.305Z I CONTROL  [main] ***** SERVER RESTARTED *****
2016-06-15T00:47:54.310Z I CONTROL  [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends
2016-06-15T00:47:54.310Z I FTDC     [signalProcessingThread] Shutting down full-time diagnostic data capture
2016-06-15T00:47:54.310Z I CONTROL  [signalProcessingThread] now exiting
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to close listening sockets...
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] closing listening socket: 6
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] closing listening socket: 7
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] removing socket file: /data/wiredtiger/mongodb-27017.sock
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to flush diaglog...
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to close sockets...
2016-06-15T00:47:54.310Z I STORAGE  [signalProcessingThread] WiredTigerKVEngine shutting down
 2016-06-15T00:47:54.436Z I STORAGE  [signalProcessingThread] shutdown: removing fs lock...
 2016-06-15T00:47:54.436Z I CONTROL  [signalProcessingThread] dbexit:  rc: 0

Как часть установки systemd сервиса я работал

systemctl --system daemon-reload
systemctl unmask mongodb.service
systemctl enable mongodb.service
systemctl start mongodb.service

Все данные, журналы и запущенные каталоги для mongodb принадлежат mongodb.mongodb - и я создал mongodb subdir/var/run (принадлежавший быть mongodb)

Что уничтожает systemd версию сразу после запуска?

Что-либо еще я могу попробовать? (Я попробовал 'LimitNOFILE=64000' в [Сервисе]),

Спасибо!

2
задан 15 June 2016 в 04:33

2 ответа

processManagement: {ветвление: верный, pidFilePath: "/var/run/mongodb/mongodb.pid"}

Это - Ваша проблема. processManagement.fork должен быть false (который является также значением по умолчанию) в Вашем mongod.conf файл.

Поскольку это верно, mongod полностью излишне разветвляется. Поскольку это разветвляется, systemd думает, что основной процесс dæmon неожиданно вышел, и это очищает сервис назад к его остановленному состоянию. Это делает это путем явного завершения всех дочерних процессов, разбросанных сервисом. Следовательно сигнал.

Это - несоответствие протокола готовности. MongoDB не говорит разветвляющийся протокол готовности, и это не корректно для изменения systemd сервисной единицы, чтобы сказать, что он делает. Это, скорее корректно для изменения конфигурации MongoDB так, чтобы это полностью излишне не разветвлялось.

Дальнейшее чтение

2
ответ дан 2 December 2019 в 02:51

Обычно - после того, чтобы уходить в течение 20 минут - я возвратился к чему-то, в чем я работал в течение многих часов и нашел решение.

Type=forking

Необходимый в/lib/systemd/system/mongodb.service файле. Который теперь похож;

[Unit]
Description=High-performance, schema-free document-oriented database
After=syslog.target network.target

[Service]
Type=forking
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod -f /etc/mongod.conf
ExecStop=/usr/bin/mongod -f /etc/mongod.conf --shutdown

[Install]
WantedBy=multi-user.target

Надежда, которая выручает кого-то еще!

1
ответ дан 2 December 2019 в 02:51

Другие вопросы по тегам:

Похожие вопросы: